• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 82 subscribers
  • Views 139 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.

TMS320F28379D: usb_dev_serial example not running from FLASH.

Valeriy Miagkov
Prodigy 60 points
Part Number: TMS320F28379D
Other Parts Discussed in Thread: CONTROLSUITE, , C2000WARE, LAUNCHXL-F28379D

I am trying to make usb_dev_serial example (C:\ti\controlSUITE\device_support\F2837xD\v210\F2837xD_examples_Cpu1)  work on my TMS320F28379D controlCARD.

Everything is operating as expected when I run program from RAM and from FLASH in debug mode. When I program FLASH and start it from debugger the program is running even when debugger is disconnected.

However, if I cycle power after that, the program will not start. The program is not starting on its own without a push from debugger. 

I tried to program the Blinky example the same way and the LED is blinking even after power cycle. The SW1 switch settings have not been changed. Both are set to 1.

 Any idea what can cause this behavior and how to troubleshoot it would be appreciated.

  • 0
    TI__Guru* 77230 points

    Valeriy,

    Since the LED blinky is working I think we can assume your boot pins are in the correct state to boot from flash on power up, but just to double check GPIO72 and 84 both have a pullup to VDDIO to get into get mode boot.

    Also, we can make sure that get mode is picking flash boot, this is controlled by the OTP see below.  If you have never programmed this region it will default to flash boot, but adding below to make sure

    9.10.3 Get Mode
    The default behavior of Get mode is boot-to-flash. This behavior can be changed by programming the Zx-
    OTPBOOTCTRL locations in user configurable DCSM OTP. The user configurable DCSM OTP on this device is
    divided in to two secure zones: Z1 and Z2. The Get mode function in boot ROM first checks if a valid
    OTPBOOTCTRL value is programmed in Z1. If the answer is yes, then the device boots as per the Z1-
    OTPBOOTCTRL location. The Z2-OTPBOOTCTRL location is read and decodes only if Z1-OTPBOOTCTRL is
    invalid or not programmed. If either Zx-OTPBOOTCTRL location is not programmed, then the device defaults to
    factory default operation, which is to use factory default boot mode pins to boot to flash if the boot mode pins are
    set to GET MODE. Users can choose the device through which to boot—SPI, I2C, CAN, and USB—by
    programming proper values into the user configurable DCSM OTP. More details on this can be found in the TRM

    I did a quick check on my LaunchPad, and I see this example boot correctly from flash.  One way you can check this with the emulator running is to perform a debug reset, then before you run, go to "Scripts" and "EMU Boot Select" and pick Boot from flash.  You can then run from the starting ROM address(the debug reset should have brought you there), and the device will behave as it does in standalone boot mode.  If you don't see this reaching your "main" then we can debug more.

    Finally, if all the above fail, would it be possible to download/install our C2000Ware support package?  This will have the most up to date examples for our devices, and is our recommended starting path.  ControlSUITE has not been updated in some time, so I'd like to ensure you still have this issue even with C2000Ware.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Prodigy 60 points

    I took a different board (LAUNCHXL-F28379D) then imported and flashed usb_ex1_dev_serial project from C2000Ware rev 5.0.0. It is actually not simple to verify operation of this project on LAUNCHXL-F28379D as it only has one USB port. I added blinking LED code to this project, and verified the project was working even after power cycle. I then verified same behavior when same project programmed on the original controlCARD. After power cycle the LED is blinking and there is some semblance of serial communication. The serial communication part is not working as well as in the controlCARD example. The serial communication reliability was not part of my original question so we can say that there is issue with the code in controlCARD example and close this support ticket.

    Others seem to have run into the same problem and had to disable watchdog to fix it. Not sure I want to do that.

    Thanks.