• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 80 subscribers
  • Views 887 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.

TMS320F28069 Hardware Lockout Problem

Robin Vice
Intellectual 950 points
Other Parts Discussed in Thread: UNIFLASH

Hi All,

I have a working program for this embedded system.  It's been running in debug and release modes without issue, until adding a write-to-flash feature.

I write calibration variables to flash, so they will survive a power/reboot cycle.

The routines write to Sector E as expected.  I can see that in debug mode.

Here's the problem:  When thecode is built in release mode, and uploaded to the device, everythings works fine, except the emulator will no longer connect to the target.  Here's the error message:

After replacing the DSP chip, all is well again, until running the write to flash routine.

Here's the breakdown of the routine, it's called store_config():  (feel free to ignore the circles and arrows)

Running the "Test Connection" utility in CCS 6 returns no problems.  It seems like the CSM password has been written to, and so it locks out the emulator connection.  But I can't find any reason for that memory to be written to.

Any ideas would be greatly appreciated.


Thanks for your input!

  • 0
    TI__Guru 57255 points

    Hi,

    The difference between 'Debug' and 'Release' mode don't always have a consistent definition.

    Therefore, I would recommend trying to figure out what the difference actually is in your project.  If you right-click the project name in CCS, you should be able to look at the project properties and then investigate the build configurations.

    If the difference is optimization, the following text may help:
    http://processors.wiki.ti.com/index.php/C28x_Code_Generation_Tips_and_Tricks#Q:_My_code_worked_well_until_I_turned_on_optimization._What_could_be_the_issue.3F

    If the difference is (also) utilizing FLASH memory vs using only RAM, you may want to look at what you're linking into FLASH vs RAM.  See also:
    http://processors.wiki.ti.com/index.php/C2000_Flash_Common_Issues/FAQs#Code_Does_Not_Run_Standalone

    Hopefully this helps.


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    Intellectual 950 points

    Hi Brett,

    I found that the optimization level in debug mode was set to 'off', but in release mode was set to '2'.  When I changed release mode to optimization level 'off', the program loaded up, I made a change to the code, reloaded, and all seemed well.

    Well, after about a dozen flash erase/write cycles of storing operating states to flash sector E, the processor was locked out from the emulator as had happened before.

    Before programming the chip this time I wrote some code to bit-bang the passwords out through a GPIO.  This time I could see that the passwords had been altered.  PSWD6 had changed from the default value of 0xffff to 0x0000.  All other passwords are still 0xffff.  I still don't know why it changed.

    I haven't used the csm feature before, so even though I knew what the passwords are, I didn't know how to use them to unlock the part.  I tried changing CsmRegs.KEY6 in SysCtrl.c from 0xffff to 0x0000, but that didn't unlock it.  I ended up using the Uniflash utility to unlock the part using the passwords I spied through the GPIO port, erase sector a, and regain connectivity in CCS.

    Is there an app note on using the csm feature?  Is it possible to completely disable the csm feature (so if its passwords are inadvertently changed, the part will still connect to the emulator)?

    When the product is ready for release, I'll want to enable the feature, but until then I'd like csm to just go away.

    Any other insights as to why the password would have changed would be greatly appreciated.


    Thanks,   Robin

  • 0 in reply to Robin Vice
    TI__Guru 57255 points

    Hi Robin,

    While you are programming Sector E are the device's power supplies stable?  The reset line?


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    Intellectual 950 points

    Hi Brett,


    I just finished testing the flash supply/gnd and XRS lines.

    I set GPIO30 hi in code the line before calling the flash routine, and cleared to low the line after the flash routine returned.  I setup the scope to trigger on the rising edge of GPIO30, so as to capture the effects of the entire flash routine cycle on XRS and Vdd3vfl.  I placed ground probes at the closest ground reference points related to the signal pins and got the following traces:

    The scope images shows the power supply and XRS pins to remain solid through the sector E flash erase/write cyce.  In addition to the above scope settings, I zoomed in tighter on each time segment to make sure there were no glitches that the above scope settings missed.  I also looked at Vdd and Vdda, and all was clean.

    The anwsers to your questions are:  Yes, the power supply and reset lines are stable.

  • 0 in reply to Robin Vice
    TI__Guru 57255 points

    Hi Robin,

    You've now eliminated my first thoughts.  A few more below:
    1) How often does the password write issue occur?  Is it possible that during the problematic write (when the flash write also flashes a password) a power supply/XRSn issue is occurring?
    2) What version of F28069 header files/linker command files/Flash API are you using?  Is it possible to try to update them to the newest?
    3) Based on the above, your originally thought was that the issue followed the build configuration.  Can you confirm that we've ruled that out now?  Does the issue still pop up more in one build configuration vs the other?  (this may be some kind of clue)
    4) From your first post, it seems like you've seen the issue occur on multiple devices.  Can you confirm that the issue can still occur on a fresh device?


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    Intellectual 950 points
    Hi Brett,
    Thanks for your response and for your questions.
    1)  I haven't been able to identify any logic as to when a password write occurs.  It seems random and I believe it's never taken more than a few dozen cycles.  I'll try to capture power supply and XRS states at the time of password write, but due the seemingly random nature of it, it's pretty iffy.
    2)  I'm using CCS v6.1, and downloaded all the current files at that time it was released (a couple months ago).  I'll look into updating them.
    3)  The only changes I've made in the build configuration was when I tried changing the optimization level in debug mode to match what it was in release, to see if the problem would appear in debug mode.  Then I changed release mode optimization to match debug mode.  Most results were inconclusive in the sense that parts of the program were broken by the changes (re: Heizenberg uncertainty principal).  But it's certain that the password write occurred in release mode even with the different optimization level.
    4)  The problem has manifested on four different taget systems.  Replacing the 80 pin DSP chip is labor intensive and vulnerable to PCB damage, so I became very cautious after the four.  I've since written code to expose the passwords, so I can now recover from a PW write without replacing the chip.  I will do some more testing to see if I can determine repeatability.
    Thanks again!

  • 0 in reply to Robin Vice
    Intellectual 950 points

    Hi Brett,

    I updated CCS and the C2000 tools to the most recent version.  I investigated the header and library files, and found there are some updates.  I haven't implemented them yet, and may not, because I haven't been able to reproduce the problem after the CCS & tools updates.

    So, the good news is that the problem seems to have disappeared, the bad news is I don't know why.

    I'll let you know if anything new develops.

    Thanks for your guidance.

    Robin