Sorry for this newbie question.
It seems to me that I should be able to use my startKit to read and write the flash on another board with an XMOS L1 chip on it.
1. Would the right approach be to connect the JTAG signals on startKit TP1 to the JTAG signals on the remote board?
2. If this is sensible, then would I cross-connect TDI-TDO between the boards, or would I connect TDI to TDI and TDO to TDO?
3. If this is not sensible, then what might be?
After taking care of hardware matters, then there's the software question.
4. Could I just fire up xflash, list devices, then directly use xflash to read and write my target device, or is it more complicated than that?
5. If it's more complicated, can someone point me in the right direction?
Use startKit to read/write flash on other XMOS board? Topic is solved
-
dhalbakken
- New User
- Posts: 2
- Joined: Sun Nov 09, 2014 8:50 am
-
mon2
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
It seems to me that I should be able to use my startKit to read and write the flash on another board with an XMOS L1 chip on it.
Sure. You can.
1. Would the right approach be to connect the JTAG signals on startKit TP1 to the JTAG signals on the remote board?
2. If this is sensible, then would I cross-connect TDI-TDO between the boards, or would I connect TDI to TDI and TDO to TDO?
Loosely speaking, the idea is more complicated than need be. JTAG could be considered to be a large serial shift register. The depth of the serial register varies with the number of devices connected within the JTAG device chain. As you clock in / out the bits, you focus the attention on the landing device to perform your task. TDI of the next sequential device would mate with the TDO of the previous device - hence creating a loop / cycle with the last device's TDO returning back to the JTAG master's TDI. However, stating this is more complex than need be as you will need to define the JTAG chain details, etc. Not currently my area of expertise so some other suggestions are...
3. If this is not sensible, then what might be?
I would consider taking 5 of 1 bit pins on the "master" startkit or consider ports which are able to work in the same direction as a group for:
1 bit for SPI_CS ; chip select for the TARGET SPI flash
1 bit for SPI_CLK ; clock for the TARGET SPI flash
1 bit for SPI_MOSI ; Master out -> Slave In on TARGET SPI flash
1 bit for SPI_MISO ; Master in -> Slave Out on TARGET SPI flash
1 bit for JTAG_Reset for the TARGET board
Wire up the above pins from the MASTER directly to the TARGET XMOS board's FLASH device.
This idea would then use the master XMOS to assert the RESET onto the 2nd XMOS device (first) and hold this level to ensure that the TARGET XMOS is tri-state and not asserting any logic levels onto the same FLASH device you wish to use with the MASTER XMOS controller.
Now, apply code such as the one posted on Github:
https://github.com/xcore/sc_flash
and use the standard SPI flash code (not the QUAD SPI which is not suitable for this project due to the wiring of the SPI flash device). Take care to use the port pins and device definition to match yours. Assert RESET on the TARGET board (hold it low while during your work); R/W with the TARGET flash as required. The small drawback to this method is that you will lose the benefit of the XFLASH tools which can assist you to load / erase / update your XMOS code. You should be in full control of the TARGET FLASH device using this approach including reflashing a new or bricked TARGET board.
Another method to consider is to hold down the JTAG RESET on the TARGET board (again to place the 2nd / Target XMOS device into tri-state mode). You do not want the 2nd XMOS controller to place any logic levels onto the same "shared" SPI flash while performing your work. Wire up the same pins from the first SPI flash (on the XMOS master) to the SPI flash (on the XMOS target). The single exception is to not wire up the SPI_CS on both devices - will require you to cut a trace or similar. Now, when you wish to access the 2nd XMOS SPI flash, connect the CS from the master to the target SPI flash. This will allow you to enable and access the 2nd device. Why take this approach ? Because you can now use the XFLASH tools to assist in the upgrade of the new TARGET board. This is a huge benefit to this method. The XMOS tools will believe the SPI flash is local. Just be sure to use the same brand / definition of the SPI flash during this experiment. On this note, did a lot of research on SPI flash devices earlier this year to enable QUAD SPI mode and made many discoveries. The github code is not stable for QUAD SPI mode use but recall it being fine for standard serial mode access. If you take the second approach, you would not even have to consider the use of the github code since the xflash s/w would perform this task.
Hope this helps.
Sure. You can.
1. Would the right approach be to connect the JTAG signals on startKit TP1 to the JTAG signals on the remote board?
2. If this is sensible, then would I cross-connect TDI-TDO between the boards, or would I connect TDI to TDI and TDO to TDO?
Loosely speaking, the idea is more complicated than need be. JTAG could be considered to be a large serial shift register. The depth of the serial register varies with the number of devices connected within the JTAG device chain. As you clock in / out the bits, you focus the attention on the landing device to perform your task. TDI of the next sequential device would mate with the TDO of the previous device - hence creating a loop / cycle with the last device's TDO returning back to the JTAG master's TDI. However, stating this is more complex than need be as you will need to define the JTAG chain details, etc. Not currently my area of expertise so some other suggestions are...
3. If this is not sensible, then what might be?
I would consider taking 5 of 1 bit pins on the "master" startkit or consider ports which are able to work in the same direction as a group for:
1 bit for SPI_CS ; chip select for the TARGET SPI flash
1 bit for SPI_CLK ; clock for the TARGET SPI flash
1 bit for SPI_MOSI ; Master out -> Slave In on TARGET SPI flash
1 bit for SPI_MISO ; Master in -> Slave Out on TARGET SPI flash
1 bit for JTAG_Reset for the TARGET board
Wire up the above pins from the MASTER directly to the TARGET XMOS board's FLASH device.
This idea would then use the master XMOS to assert the RESET onto the 2nd XMOS device (first) and hold this level to ensure that the TARGET XMOS is tri-state and not asserting any logic levels onto the same FLASH device you wish to use with the MASTER XMOS controller.
Now, apply code such as the one posted on Github:
https://github.com/xcore/sc_flash
and use the standard SPI flash code (not the QUAD SPI which is not suitable for this project due to the wiring of the SPI flash device). Take care to use the port pins and device definition to match yours. Assert RESET on the TARGET board (hold it low while during your work); R/W with the TARGET flash as required. The small drawback to this method is that you will lose the benefit of the XFLASH tools which can assist you to load / erase / update your XMOS code. You should be in full control of the TARGET FLASH device using this approach including reflashing a new or bricked TARGET board.
Another method to consider is to hold down the JTAG RESET on the TARGET board (again to place the 2nd / Target XMOS device into tri-state mode). You do not want the 2nd XMOS controller to place any logic levels onto the same "shared" SPI flash while performing your work. Wire up the same pins from the first SPI flash (on the XMOS master) to the SPI flash (on the XMOS target). The single exception is to not wire up the SPI_CS on both devices - will require you to cut a trace or similar. Now, when you wish to access the 2nd XMOS SPI flash, connect the CS from the master to the target SPI flash. This will allow you to enable and access the 2nd device. Why take this approach ? Because you can now use the XFLASH tools to assist in the upgrade of the new TARGET board. This is a huge benefit to this method. The XMOS tools will believe the SPI flash is local. Just be sure to use the same brand / definition of the SPI flash during this experiment. On this note, did a lot of research on SPI flash devices earlier this year to enable QUAD SPI mode and made many discoveries. The github code is not stable for QUAD SPI mode use but recall it being fine for standard serial mode access. If you take the second approach, you would not even have to consider the use of the github code since the xflash s/w would perform this task.
Hope this helps.