F28E120SC: parallel GPIO bootloader seems to not work

Part Number: F28E120SC

Hi, 

I have met a problem with loading the program to the RAM using parallel boot mode. I have used this method 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 internal memory 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. have the parallel Boot mode for F28E120SC changed? 

Best regards,

Tomas Lehotsky

 

  • Hello,

    TMS320F28003x/280013x/280015x

    Parallel boot mode should not have changed between F28E12x and those devices. It was a design requirement for them to maintain compatibility.

    What parallel boot option (0x00 or 0x20) and F28E120SC package are you using?

    Best,
    Matt

  • Hi Matt,

    we are using 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

    Best regards,

    Tomas

  • Hello Tomas,

    Thank you for confirming that for me. Can we try the following:

    1. Sending any default SDK example (built for RAM) and see if the issue occurs again?
    2. Emulating parallel boot (using the EMU boot registers) and see if the issue occurs. If it does, load the Boot ROM symbols and observe where the ROM bootloader is getting stuck.
      1. Please refer to SPRUJH3 for details. In particular:
        1. Section 2.2 Emulation Boot
        2. Section 5.3 No Symbols Defined When Debugging Boot ROM

    Best,
    Matt