• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 424 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

TMS320F2800137: Boot Mode in DCSM

TMS320F2800137: Boot Mode in DCSM

H F
Prodigy 130 points
Part Number: TMS320F2800137


Tool/software:

Expanding on this :

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1391394/tms320f2800137-boot-mode-in-dcsm/5322270#5322270

Is this all I need to configure? I don't want to lock the device or require any password. I also want to be able to program both RAM / Flash through a external debugger ( for example xds200 ) . Will that be an issue? 

And then i just copy the 2 dcsm files to any simple project eg led blinky and upload?

and these pins . What should I set them to ? To flash or Wait Boot mode?


  • 0
    TI__Mastermind 28300 points

    Hi HF,

    With the configuration you've shown, the device will always operating in SPI boot on reset. However the debugger will still be able to take over the program counter if you want to debug. Since you've disabled your boot mode select pins (number of boot pins set to 0), it does not matter what you configure GPIO24 and GPIO32 to. Let me know if this is your desired configuration.

    Thank you,

    Luke

  • 0 in reply to Luke Jones
    Prodigy 130 points

    Thank you for clarifying. Yes this is my desired configuration, but I would still like to upload program through the debugger as well. What boot option should I have for that ? 

    On default , the boot pins on the device can be set to anything and we can still upload program via the debugger. Will we lose this ability when we set it to only SPI boot?

    This is what I get from your statement : 

    However the debugger will still be able to take over the program counter if you want to debug

  • 0 in reply to H F
    TI__Mastermind 28300 points

    Hi HF,

    As long as you don't have security enabled (which you don't) you can have any boot mode selected and the debugger will be able to take control of the device to upload or step through your code.

    Thank you,

    Luke

  • 0 in reply to Luke Jones
    Prodigy 130 points

    Yes , Thank you ! It works

    Another issue we're having is , the "emulated" boot mode worked perfectly for uploading code via SPI. Now that we're trying by this "permanent" one, there seems to be a timing mismatch of some sort? We reset in both cases, is there any difference between the two?

  • 0 in reply to H F
    TI__Mastermind 24980 points

    Hi HF,

    To clarify, are you able to run SPI standalone boot mode correctly after programming the OTP, and now you are only seeing a timing issue in the SPI when loading? Have you been scoping the SPI lines to see if the data transactions and timing looks as expected? Are the devices using the same SPI clock mode?

    Best Regards,

    Allison

  • 0 in reply to Allison Nguyen
    Prodigy 130 points

    Yes, SPI standalone boot mode is correctly programmed , we can see the clocks on a scope. It's not a SPI mode issue as it was working perfetly fine with the emulated SPI boot mode. We think its maybe becasue of the reset , or Chip Select not behaving as we think as the device on the other end ( an ESP32 ) seems to be considereing an extra CS right at reset 

  • 0 in reply to H F
    TI__Mastermind 24980 points

    Hi HF, 

    Do you perhaps have an image of the scope with the chip select behavior you think is causing this? Is there a particular symptom of the issue that you are seeing -  is the CPU getting stuck in the SPI bootloader in a particular spot? And what is the part number of the other device? Does the other device documentation in comparison to the scoped behavior give an indication of where the signal may have been misinterpreted?

    Best Regards,

    Allison