• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 83 subscribers
  • Views 570 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

F28M36H33B2: Blinky example Flash-Standalone works on ControlCard but not on my target device

Albert Smit
Intellectual 730 points
Part Number: F28M36H33B2
Other Parts Discussed in Thread: F28M36P63C2, CONTROLSUITE

I have been developing my code using only RAM build. Now that I want to put it on the flash for standalone operation, it does not work.

I reverted back to the blinky example code, it works perfectly on the controlCard with concerto F28M36P63C2. I build flash-standalone, load it, remove the emulator, reset and both led's start flashing. When I load the exact same flash-standalone build blinky example code on my target device, which is a concerto F28M36H33B2, and only change the pin definitions since my led's are on different pins, it does not work. I know the code works fine because when I do a RAM build it works on my target device, both the blinky example and my own code. Also when I do a flash build (not standalone) on both M3 and C28, it also works when I start it with the debugger, but obviously if I remove the debugger and reset only the M3 starts because it does's send the boot command to the C28.

So in summary, when I load the flash-sandalone blinky example code on the controlCard it works, but on my own device it doesn't work, none of the led's start blinking when I reset it. Why would that be, the only difference is the concerto devices? Do I have to change something in the command linker file when I move from the controlCard to my target device? I use the blinky example v206 in controlSuite.  

Thanks

Albert

  • 0
    Guru 192875 points
    Hi Albert,

    What is the boot pins configuration on your target board?

    Regards,
    Gautam
  • 0 in reply to Gautam Iyer
    TI__Guru** 113695 points

    As mentioned by Gautam, please make sure default BOOT pins GPIO43/GPIO47GPIO35/GPIO34 have proper value on your target board to boot from flash. 

  • 0 in reply to Vivek Singh
    Intellectual 730 points

    My boot pins are all pulled high with external pull-up resistors, which is boot from flash mode (datasheet Table 6.17, p193). According to the datasheet the boot pins are on GPIO43, GPIO47, GPIO35, and GPIO34. Why are you saying GPIO72 and GPIO84 must also be 1? GPIO72 is SSI0/SPI and GPIO84 is SSI3/EMAC. Do I have the pins wrong?

  • 0 in reply to Albert Smit
    TI__Guru** 113695 points
    Albert, you are right. On this device boot pins are different. I have corrected the same. You also mentioned that M3 starts properly but not C28x. If that is the case then boot process is ok. Do you know if M3 code executes till end (past the step where it sends IPC message to C28x) Are you using the same CCS setup for both ?
  • 0 in reply to Vivek Singh
    Intellectual 730 points

    M3 Starts correctly when I load flash build, but when I load flash-standalone build it does not. No, it seems to be hanging in the while loop inside IPCMtoCBootControlSystem(CBROM_MTOC_BOOTMODE_BOOT_FROM_FLASH). I saw this by loading the flash-standalone, power cycle and then re-connect the emulator which then hangs at the above line. 

    Strangely, I have now noticed that the Blinky example randomly works some times and sometimes not. My own code always hangs on the  IPCMtoCBootControlSystem though.

    If you say CCS setup for both, exactly what are you referring to? I have a project folder for the C28 and and a Project folder for the M3. I only setup the build configurations for each to use the correct .cmd files for my own project. For the Blinky example I'm using the Setup as it is in controlSUITE. 

  • 0 in reply to Albert Smit
    Intellectual 730 points

    The problem was hardware related. The reset circuit did not have the correct resistor values. So everything worked when it was manually reset with the debugger, but when it had to reset by itself after a power cycle, it did not reset correctly.