Part Number: F28E120SC
Hi,
this is the consequent thread of closed thread "F28E120SC: parallel GPIO bootloader seems to not work". Can be this thread re-open?
I have a problem with loading the program to the RAM using parallel boot mode. I have used the same algo for TMS320F28003x/280013x/280015x devices and everything is working fine. The same parallel GPIO bootloader algorithm is not working for the F28E120SC. It seems like the device "stuck" after some words have been transmit to the RAM of the device.
I have the saleae captured file where you can see what happened:
F28E120Sx_parallel_problem.zip
At the end of the captured data you can see, that after last byte 0xFF is send to the device, the F28x control pin (DSP in saleae) is putting High, then the Host control pin us putting to High, but the device do not pull the F28x contorl pin to low(indicates the device is ready for more data). I have a 500ms timeout for this, I try to expand this time to 1s, 2s 10s but the device never pull the C28x control pin to low.
In the captured data you can see that I try to store ten words(0x0A) of data 0000 0003 C84D 0000 0010 FFF0 0000 0003 0001 0000 to address 0x128 - M0RAM. After sixth word the algorithm stuck.
As I wrote, we don't have problem with loading data in this manner to previous TMS320 series.
I use the brand new F28E12SCTPT devices in LQFP48 package with the default pre-programmed values of DCSM. The GPIO24 and GPIO32 are set to L - parallel IO Boot Mode. So I suppose that the device have configured boot option 0x00. For communication we use:
DSP control - GPIO224, pin 6
Host control - GPIO242, pin 5
D0-D7 - GPIO0,1,3,4,5,24,28,29, pin 42,41,39,38,47,27,2,1
I build the SDK project led_ex1_blinky for RAM. Debugging this project work fine using the XDS200USB debugger and CCS theia 20.5.1. The LED is flashing on GPIO33 pin.
Are you able to test parallel boot loading at your side?
Best regards,
Tomas Lehotsky