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.

CCS/TMS320F28069: JTAG Connection With Flash API

Part Number: TMS320F28069

Tool/software: Code Composer Studio

In a project that I am writing there is a program running in one sector of Flash and RAM which writes data to other Flash sectors using the Flash API in ROM. When this program is using the Flash API to write/erase Flash would you recommend having JTAG disconnected?

In the past two or three weeks I have experienced some strange behavior when this program writes/erases Flash with JTAG connected (and often with the CCS Expressions view on Continuous Refresh). This has caused two microprocessors to act abnormally and appear as though Flash and the Flash registers are completely unavailable via JTAG. Also the program on the microcontroller is no longer able to write/erase the other sectors of Flash on these two devices. When it runs without JTAG I have never seen this problem. Thank you for your help with this issue.

  • Hi,

    It is not recommended to run the flash API from one of the section of Flash and erase/program other sector of Flash. You need to run Flash API from RAM only for erase/program operation of flash sectors.

    Regards,

    Vivek Singh 

  • Hello Vivek,
    I realize that the API calls need to happen from RAM, that is why I mentioned that the program runs from Flash and RAM. What I am wondering is whether debugging the processor with JTAG connected could cause unpredictability when the Flash API is writing/erasing Flash sectors.
  • Rolf,

    JTAG connection should not cause any unpredictability. Looping in our flash expert to provide his comments as well.

    Vivek Singh
  • Vivek,
    Thank you for looping in one of your Flash experts. I will be interested for any insight that they might have.

    Regards,
    Rolf Olsen
  • Rolf,

    As Vivek said JTAG connection shouldn't cause any unpredictability. Did you check whether your devices are in depletion? Do you get any error message when flash write / program fail.

    Regards,
    Manoj
  • Hello Manoj,

    I tried running the depletion recovery function in the On-Chip Flash window which gave the following error:

    There was a valid connection to the processor in the Connection window:

    When I try to load a program to the processor I get the following error and console messages:

    One other strange thing is that the Flash registers on this microprocessor return all zeros:

    as does the beginning of Sector A in Flash:

    This is strange because the CSM on the processor was unlocked at the time of the error and now the processor successfully runs a program that is written in Flash Sector A with some functions copied to RAM when the program starts (including the functions that call the Flash API). The program does now give errors when it tries to access Flash. If I wasn't able to connect to the processor via JTAG and see variables and instructions that exist in RAM I would think that the CSM is locked but my belief is with the CSM locked I would not be able to connect to the processor via JTAG without entering the correct password.

    When the error occurred I hit an illegal operation trap which I believe from the contents of the stack occurred when the processor was returning from the Flash API function to the function call in RAM. It seems that the return program counter was corrupted for some reason to a location in Flash that contained a trap instruction. At the time this occurred I had a number of variables (including some variables that are located in Flash) in the Expressions window and continuous refresh was enabled. This problem has now happened to me two times in the last three weeks out of thousands of times this program has written to Flash successfully over the past few years (the program used was compiled 6/2016) with a similar JTAG connection. Because of this I wonder if a recent change to Code Composer could be contributing to this problem.

    Do you have any idea what is going on? What other information can I give you which might help us determine the cause of this error and why Flash on the processor is not accessible? I appreciate any feedback and help that you can give with this issue.

    Thank you for your help,

    Rolf Olsen

  • Rolf,

    I'm confused. Is this a new project (or) existing project which you trying to use? Do you see this behavior of every single device (or) isolated to few device (in other words, are you claiming this is a device quality issue?)

    I believe it is too early to assume recent CCS changes are causing this issue.

    Clearly from the error message and CCS memory window snapshots, the device is in locked state. Now, if ECSL password (which is part of CSM pwd) programmed, you need to enter wait boot mode (or SCI / parallel boot mode) to connect to the device and unlock the device.

    Are you trying to erase Flash SectorA when you trying to run from Flash SectorA (out of RAM)?If so, when the function returns to sectorA, it will read FFFFs and issue illegal instruction trap.

    Regards,
    Manoj
  • Hello Manoj,
    This is a new project that we have written. It is a bootloader that is stored in Flash sector A on the processor and which enables communications peripherals to update sectors B-H with the main firmware that the device runs during normal operation. When the main firmware is written it jumps to that program.

    This has happened to two F28069 processors but it has only happened at my desk when I have a JTAG emulator connected and active. The strange thing is that I have been working with the processors this way using this identical bootloader for a long time but have only had this issue occur two times, both in the past month. The problem is this processor now appears unusable.

    This program did not have a password written to the CSM and avoids writing to the CSM password area of sector A. I also find it very strange that the processor was operating normally with the CSM unlocked, then an ISR_ILLEGAL occurs due to an illegal operation trap (which seemed to happen when the processor was returning from a Flash API function) and then Flash on the processor is locked.

    No, the program only erases the sectors B-H that will subsequently be updated with new data. The Flash API command to erase FlashA is blocked and should never occur. It was performing the Flash API function to write Flash when the illegal interrupt occurred. The return location when the illegal interrupt occurred should have been an instructions in RAM but for some reason the RPC seemed to get corrupted. Also, the processor continues to run the bootloader program located in sector A.

    One other thing, I have experience using the processor with the CSM locked, booting with wait mode, entering the password and then debugging the processor. You mentioned that you are sure that the processor CSM is locked but I am able to connect to the main CPU and look at RAM without entering wait boot mode (I can connect when it uses get boot mode). If it were locked I would expect an error dialog box to appear and the JTAG connection attempt to fail. Unless I am missing a detail I believe this indicates that the Flash CSM is not locked and something else it going on.

    I do have quite a bit of additional information that I captured when the illegal interrupt occurred if there is more that you would like to know. I am very interested in better understanding what happened so I can prevent this from happening in the future because replacing the processor is an involved process which will stress the board and other components.

    Thank you for your assistance!

    Regards,
    Rolf
  • Rolf,

    Thanks for detailed explanation. I believe I understand the problem better now.

    You will be able to connect to CSM locked device without JTAG tripping on you if ECSL password isn't programmed.

    SectorA and SectorH are balanced sectors. Flash reads on Sector A can get affected by the VT (voltage threshold) states of SectorH. If Sector H is in depletion it is possible that SectorA CSM password location might possibly read a non 0xFFFF value which can lock the CSM. It is possible that ECSL password locations within CSM appear 0xFFFFs and hence JTAG doesn't trip.

    Unfortunately I don't have readymade answer. You can get to the bottom of this issue only through proper debug. But, If i were you I would look into below questions:-

    When Sector H / B is being erased, is Flash API being interrupted in the middle of operation? Also, did you find the address location which caused illegal intruction trap? What is the source of that corruption? Did you already try increasing stack size etc?

    Regards,
    Manoj

  • Hello Manoj,
    I have examined all sections of code where we use the Flash API to erase Flash sectors and interrupts are disabled so I do not think an interrupt when erasing Flash could have caused an interruption. Examining our code I found that the Flash API callback pointer is assigned a zero which should cause the Flash API to skip the callback. One thing I did notice when ISR_ILLEGAL occurred was the area of Flash that was being updated in sector F was partially written. For some reason the Flash API did not complete writing all of the data that it should have given the arguments that it was called with. Also, the flash status structure that was passed to the Flash API function contained all 0x0. One thing that potentially could have interrupted the Flash API is the Code Composer Expressions window reading values from the processor since it was set to Continuous Refresh. Do you think that is a possibility?

    Based on the values that were pushed on the stack the illegal instruction trap occurred at address 0x3F1AAA. That area of Flash was unwritten and had 0xFFFF which is what caused the illegal instruction trap. The program should never have jumped to that position in memory.

    I am not sure what could have caused the program counter to move to 0x3F1AAA, from what I can tell the Flash API function Flash2806x_Program() returned because the SP was at the position that it should be at for the function that called Flash2806x_Program() when the illegal instrunction trap values were pushed onto the stack. Therefore I believe it is most likely that the return address used by Flash2806x_Program() was 0x3F1AAAA, I am not sure how this could have happened.

    After the trap occurred and JTAG paused in the ISR_ILLEGAL function ESTOP the SP was at 0xAC, we have a maximum stack size of 0x300 words so the stack was nowhere near the end.

    I look forward to any feedback/ideas that you have regarding this issue. Thank you very much for your help.

    Regards,
    Rolf
  • Rolf,

    You shouldn't reading the flash continuously when flash is trying to erase / program (or) any other flash API function. This is mentioned in API Don'ts Flash2803x_API_Quickstart.pdf. Please check the API do's and don'ts in that reference guide.

    Regards,
    Manoj
  • Rolf,

    Did you try programming / erasing flash with continuous refresh disabled? What was your result?

    -Manoj
  • Any updates? were you able to get the issue resolved? If so, please mark "Verify Answer" to this post which resolved the issue. This will help other customers with similar problem.
  • Hello Manoj,
    We have programmed the microcontrollers many many times with JTAG disconnected without this occurring. The only time we program it with JTAG connected is when we are doing development work and debugging in the processor. I have now started to disconnect JTAG in CCS when this program updates Flash to prevent this from happening again.

    The situation that I think may have happened is that Continuous Refresh tried to read data from Sector H while the Flash API was writing data to Flash in Sector F. Do you think this could have caused any problems (for example Sectors A and H to have become unbalanced as you mentioned previously)?

    Also, if Sectors A and H are no longer balanced is there any way to recover this situation or must the chip be replaced?

    Thank you for your help!

    Regards,
    Rolf
  • Rolf,

    Sectors A and H are balanced sectors by hardware design. It cannot be changed.

    Yes, Flash API document clearly documents users not to Execute code or fetch data from the flash array or OTP while the flash and/or OTP is being erased, programmed or during depletion recovery. So, You shouldn't be accessing any flash sectors / OTP when flash API is being executed.

    I do believe continuous refresh reads is the problem. Once the flash is depleted , if the depletion recovery algorithm fails there is no way to recover the device. In that case you have to replace the device.

    Regards,
    Manoj
  • Rolf,

    I believe I have answered all your question. Can I close this thread? Hope the issue is resolved.

    Regards,
    Manoj
  • Hello Manoj,
    I verified one of the answers to close this thread. Thank you for your help answering my questions.

    Regards,
    Rolf