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

Unable to access FLASH

Filippo Cona
Intellectual 450 points
Other Parts Discussed in Thread: TMS320F28335, UNIFLASH

Hi all,

I've been working for a while on a TMS320F28335 (on a custom board), using CCS 5.5 and XDS200.

All of a sudden, I'm not able to work with the FLASH anymore: I cannot neither program it nor erase it.

I also tried to "erase cores" with uniflash, but with no luck.

The erase cores command gave the following message in the console:

[14:22:29] Erasing flash sectors on Core 0 < Texas Instruments XDS2xx USB Emulator/C28xx > ...
[14:22:33] Begin Erase Flash operation.
[14:22:33] C28xx: Erasing Flash memory...

[14:22:53] ERROR >> C28xx: Flash Programmer: Error erasing flash memory. Flash operation timed out waiting for the algorithm to complete. Operation cancelled.

[14:22:53] Flash operation Erase failed on core Texas Instruments XDS2xx USB Emulator/C28xx .
[14:22:54] ERROR >> C28xx: Error: (Error -2130 @ 0x87EE) Unable to access device memory. Verify that the memory address is in valid memory. If error persists, confirm configuration, power-cycle board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 5.1.402.0)

[14:22:54] ERROR >> C28xx: Trouble Halting Target CPU: (Error -1141 @ 0x0) Device is not responding to the request. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 5.1.402.0)

[14:22:54] ERROR >> C28xx: Unable to determine target status after 20 attempts

[14:22:54] ERROR >> C28xx: Failed to remove the debug state from the target before disconnecting.  There may still be breakpoint op-codes embedded in program memory.  It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

[14:24:59] Operation Erase Flash returned.

I tried to program a couple of boards, different hosts and tried also a different debugger (XDS100v2), always with the same result.

I guess the problem is due to the last SW I could program to the FLASH, that seems to be preventing the debugger from keeping control of the board (notice "Flash operation timed out waiting for the algorithm to complete."). Is this thing possible? Can I use uniflash or any other tool to restore the microcontroller to factory condition?

Thanks for any help ,

Filippo

  • 0
    TI__Guru 61235 points

    Hello Filippo,

    Filippo Cona said:

    I tried to program a couple of boards, different hosts and tried also a different debugger (XDS100v2), always with the same result.

    This is telling.  Since the problem exists with multiple boards, it suggests it is not a chip damage issue.  Also, by several different hosts, I assume you mean PCs.  So, probably not a SW installation problem.  And, you tried another emulator so not an emulator problem.  As you said then, maybe there is something about the SW you stuck into the flash before the problem occurred.

    Does your software program the CSM passwords?

    Regards,

    David

  • 0 in reply to David M. Alter
    Intellectual 450 points
    Hi David,
    First of all thanks for the prompt reply!
    I'm not using the CSM passwords, I also made a memory dump of the flash memory to check that I didn't mess them, but I see 8 "FFFF" where the CSM passwords should be, so I guess the device is unlocked.
    Moreover I read that if the device were locked I should get a different error message that says explicitly that the device is locked, but this doesn't seem to be my case, or am I misunderstanding something?

    Regards,

    Filippo
  • 0 in reply to Filippo Cona
    TI__Guru 61235 points
    Filippo,

    I agree with what you said. I think you would get a different error message if the CSM where locked, although I was thinking the CSM had disconnected your JTAG when the code fetched from the flash, so I wasn't sure what error message you would get. Also you say you're not using the CSM in your code and you see all 0xFFFFs in the password locations. So yep, I think your CSM is unlocked and that is not the problem.

    So then the issue you're seeing is very strange. To be clear, you've tried multiple boards, AND multiple PCs? Can you take a PC and completely clean CCS and Uniflash from it. Then re-install one (or both) and try again?

    Also, do you happen to have a TI dev board (e.g., ControlCard) that you can try to flash, just to see if it works?

    Regards,
    David
  • 0 in reply to David M. Alter
    Intellectual 450 points
    Hi David,
    Yes, I've tried multiple boards (just to be quite sure it is not a service voltage/short problem) and multiple PCs (mine and the one of my colleague that is responsible for testing activities).
    I've just tried to program the flash of a eZdsp TMS320F28335 and it worked fine, so it should not be a problem of CCS. To be clear, on the eZdsp I programmed another SW (SW2) written for the same microcontroller, in orderto avoid wasting also the dev board if my SW (SW1) is responsible for the problem. Needless to say that I cannot program also SW2 on my custom board.
    Based on these observations I'd like to avoid reinstalling CCS, but if you say that it might still lead to the solution I'll try as soon as possible.

    Regards,

    Filippo
  • 0 in reply to Filippo Cona
    TI__Guru 61235 points
    Filippo,

    If you are able to flash the eZdspF28335 board, then CCS is not the problem. It seems like CCS is working.

    So you're able to connect to your board using CCS, and you can poke around in the memory, look at stuff, etc.? You said you could. And everything is fine until you flash the device with this particular code you have, but as soon as you flash this code you cannot re-flash after that?

    Is your eZdsp socketed?

    - David
  • 0 in reply to David M. Alter
    Intellectual 450 points
    David,
    If I flag the "load symbols only" option in the debug configuration I can connect to my target board, and e.g. check the memory and the CSM passwords.
    I'll try to better explain the story: I have two custom boards, which I programmed with no problems till this morning. They both stopped working (I can't interact with FLASH) after I programmed on them the latest version of my SW. For this reason I suppose this SW is responsible for the problem, and I tested the eZdsp with another SW (just to be sure), even if two cases are not much for a statistics. I can program the eZdsp, while my custom boards are unresponsive with any SW I try to program.
    So I guess the answer to your first two questions is "Yes", while for the question "Is your eZdsp socketed?" I don't know what you mean, can you explain?

    Thanks for the support,

    Filippo
  • 0 in reply to Filippo Cona
    TI__Guru 61235 points
    The socket question asks if the F28335 is soldered onto the eZdsp board, or if it is in a socket. There are two eZdsp boards. One with the chip soldered down, the other has a clam-shell socket for the chip. If your eZdsp is socketed, there is very little risk to trying to flash your code into the eZdsp. If it screws up the device, you just pop a new one into the socket.

    Are you doing anything with the flash in your code? That is, using the flash APIs to provide for in-field re-flashing of the device? I'm trying to think what could be causing problems here. I'd agree that two boards is not much of a sample size I suppose. It is possible that the flash is damaged on both, although that seems awfully coincidental.

    - David
  • 0 in reply to David M. Alter
    Intellectual 450 points
    Hi David,
    I just realized that my last reply was not delivered correctly... Briefly, I have the socketed version of the eZdsp, but now it is a bit hard for me to obatin other microcontrollers. For the other question, my code isn't doing anything (at least by purpose) with the FLASH.

    However, in the meanwhile I investigated more thoroughly the .map file and I saw something I really don't like:

    address data page name
    -------- ---------------- ----
    00327000 c9c0 (00327000) __stack
    00327000 c9c0 (00327000) _c_int00

    00327048 c9c1 (00327040) __args_main
    00327062 c9c1 (00327040) __nop
    00327063 c9c1 (00327040) __register_lock
    0032706b c9c1 (00327040) __register_unlock

    00327080 c9c2 (00327080) __unlock
    00327082 c9c2 (00327080) __lock
    00327084 c9c2 (00327080) _exit
    0032709b c9c2 (00327080) C$$EXIT
    0032709b c9c2 (00327080) _abort
    003270a8 c9c2 (00327080) ___TI_cleanup_ptr
    003270aa c9c2 (00327080) ___TI_dtors_ptr

    So things that usually are allocated in RAM (most impressive is __stack), are now allocated in FLASH. I solved the allocation problem correcting the linker script, however my problem now is:
    - may my problem be due to the fact that symbols like __lock and __unlock are in FLASH?
    - how can I recover the boards?
    I was thinking to start the boards with a boot from RAM (thus bypassing everything that is related to interactions with FLASH), stop the execution and reset the FLASH, for example using the FLASH api.
    What do you think about this analysis and the potential solution? I cannot test it right now, since I won't be at the office for a couple of days.

    Thanks for the support,

    Filippo
  • 0 in reply to Filippo Cona
    Intellectual 450 points

    Hi David,

    I managed to recover the boards with the approach described in my previous post: I modified the linker script to boot from RAM, while the code was running on RAM I remodified the linker script to boot from FLASH, and voilà, FLASH correctly erased and written.

    Before reloading the code that runs on FLASH, I made sure that the symbols __stack, __lock and __unlock were not located in FLASH anymore, and this is the only difference that there is between the SW that hung the boards and the one that works correctly, so that must have been the issue.

    Thanks again for the support!

    Best regards,

    Filippo