• State Resolved
  • Locked Locked
  • Replies 18 replies
  • Answers 2 answers
  • Subscribers 84 subscribers
  • Views 3060 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.

CCS/TMS320F28069: Failure to Load cinit Causing Low Power Mode

Syed Hasan42
Intellectual 340 points
Part Number: TMS320F28069
Other Parts Discussed in Thread: CONTROLSUITE

Tool/software: Code Composer Studio

Everyone

I recently found out (experimentally) that if the cinit does not load properly, then the TMS320F28069 will go into low power mode. Here's how found this out:

I'm currently testing my custom bootloader which is entirely contained in sector A. If the application code does not need to be updated, then the application code gets executed (which is in sectors B to H). My c_init00() function, which initializes cinit, is located in sector A. All the cinit variables that are associated with the bootloader are in sector A. However, for the application code, I set aside a range of address in sector H that can be used for cinits that are needed for the application code. I did this using the linker command file.

The order in which the C2000 Hex Utility will arrange the data in the hex file is based on the arrangement of the linker command file. Meaning, if I put the cinits in the beginning of the SECTIONS part of the linker command file, then that's what will be put first in the hex file.

When force a communication break during the bootload process, it will go into low power mode but only if the communication break happens early in the bootloading process. If it occurs at any other time, then it won't go into low power mode.

My question is this: is there a setting or command to tell the MCU not to go into low power mode if cinit fails to initialize? Instead, is there a way to get it into some other failure mode? I ask because if it goes into low power mode, then it won't boot to flash. Instead, I have to force it to a separate boot mode before I'm able to use the bootloader again (which isn't feasible for a field release).

Thank you.

  • 0
    Guru 30330 points
    Syed,

    I have added our bootloader expert to this thread, hopefully he can be of some help.

    How are you able to tell if the device is operating in low power mode? do you attempt to connect to the device and the debugger reports this Error?: "C28xx: Error connecting to the target: (Error -1155 @ 0x0) Device may be operating in low-power mode. 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). "

    Regards,
    Mark
  • 0 in reply to Mark Labbato
    Intellectual 340 points

    Mark

    Thanks for responding. To answer your question, I'm able to determine that it's in low power mode by connecting the device to the debugger. It produces the exact same error that you described above.

    The only way to get out of low power mode is to pull down one of the GPIO pins used to determine the boot mode on power up. After that, I'm able to load using the JTAG port.

    Syed

  • 0 in reply to Syed Hasan42
    TI__Guru 55700 points

    Syed,

    You get this error because CCS was unable to connect to the device. Low power mode is just one possible scenario. You can also get this error when ECSL is tripping your JTAG connection when device is accessing secure memory. Is your ECSL password (part of 8 byte CSM password) is programmed?

    Regards,

    Manoj

  • 0 in reply to Manoj Santha Mohan
    Intellectual 340 points
    Manoj

    Thanks for the response. I'll try to find this out. However, I think I should give a few more details:

    The goal of my project is to be able to load new application code to the device without the JTAG port. Instead, the user should be able to load using a serial connection.

    In my CCS project, when the board boots to flash, the board waits to see if it receives a specific set of characters (via SCI). If it does, it goes to SciBoot in ROM. From there, a modified version of "f28069_flash_kernel", which is in controlSUITE, is loaded to RAM. The only major difference between the one in controlSUITE and my version is that sector A is not erased (because that's where the code that determines whether or not to start bootloading resides).

    Then, "f28069_flash_kernel" will load the application code to flash. To clarify what I mentioned earlier, if I cut communication between the computer and the TMS320F28069 when flash_kernel is trying to load the cinit portion of the hex file, then I'm not able to restart the bootloading process or connect using CCS. However, if I cut communication after I load cinit, then I can still reattempt my bootloader and I can connect to CCS using my JTAG port.

    Since I'm able to normally connect to CCS using a JTAG port, I would assume that the ECSL password is normally being programmed. However, in this edge case, I wonder if the ECSL password can't be programmed because it needs some global variable in cinit. That would explain why this normally wouldn't happen. I'll try and do some digging to see where, if at all, the ECSL is being programmed.

    Syed
  • 0 in reply to Syed Hasan42
    Intellectual 340 points

    Manoj

    Firstly, I can't determine whether or not ECSL is getting programmed on power cycle when this error occurs. The problem is that when that error appears, I can't use the debugger to determine if it was successfully unlocked.

    Secondly, I want to emphasize that this issue occurs even when I'm not using JTAG. Meaning, this can happen when the only connection to my computer was the serial connection (SCI). If I interrupt this communication while the flash kernel is loading the cinits, and then power cycle the board, I'm not able to reconnect to the board using my serial connection. However, if I interrupt the communication at any other time, such as when the flash kernel is loading the .text part of the hex file, I'm still able to connect to the device using my serial connection after a power cycle. Also, once the program is completely loaded with the bootloader, it will never go into low power mode no matter how many times I power cycle the device.

    Because of this, I don't think the flash is being locked. After all, it was actually locking the device, it should be doing this every time, even if the bootloader successfully loaded the code to flash. Furthermore, I checked my code, and I'm not using a password to lock flash (the password is still set to the defaut FFFF).

    Essentially, it seems to me that there's a bug in the chip such that if the cinits are not populated, then the device will go into low power mode. When it does this, I can't reattempt my bootloader. Even though I know how to get it out of low power mode (pulling down one of the GPIO pins that's used to determine the boot mode), most of my users of the device won't know how to do this. Also, the users of this device won't have access to the JTAG port.

    My question is this: how can I make sure the F28069 won't go into low power mode even if cinits are not fully populated?

    Syed 

  • 0 in reply to Syed Hasan42
    TI__Guru 55700 points

    Syed,

    The device shouldn't go into low power mode just because communication was broken during .cinit hex code process. It is my understanding that you claim the device is in low power mode because CCS report so while connecting. Have you checked whether the supply currents on VDDIO / VDD to confirm whether you are in low power mode? If you don't see any reduction in supply currents, it is too early to confirm that device is in low power mode.

    Also, ECSL password is a part of CSM password and we need to know what was programmed in the last eight locations of Sector-A (0x3F7FF8 - 0x3F7FFF). One way to connect to CCS on a locked device is to get the device in Wait boot mode. You can get the device in wait boot mode by pulling GPIO37 high and GPIO34 low. Once you get connected to the device, please provide the contents of 0x3F7FF8 - 0x3F7FFF.

    Regards,

    Manoj

  • 0 in reply to Manoj Santha Mohan
    Intellectual 340 points

    Manoj

    Sorry for not getting back to you sooner. When I interrupted the bootloader while it was loading the cinits to flash, and then cycled power, the board was drawing a total of 48mA. To be clear, this is when I'm not able to use the bootloader or the JTAG port to reload code to the flash (except by manipulating GPIO34 and 37 on startup).

    Concerning your second point, after putting the board into wait boot, I found that all eight locations had FFFF. This matches what's normally there when the error isn't present and the bootloader is successful.

    These two results seem to be contradictory. Because of the high current draw, it seems unlikely that it's in low power mode. However, I doubt that the flash is locked because passwords are not different from what they normally are.

    Is there anything else besides low power mode or a locked device that could generate that error code?

    Thanks.

    Syed 

  • 0 in reply to Syed Hasan42
    TI__Guru 55700 points
    Syed,

    I believe this is your application code issue and not device issue.

    Do you have any part of code which would erase sector A? I'm wondering whether erase operation of sectorA is getting interrupted. This can also lock your device and give this below error:

    "C28xx: Error connecting to the target: (Error -1155 @ 0x0) Device may be operating in low-power mode. 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). "

    Did you check whether Flash memory is corrupted when you get this error? Also, have you re-ordered cinit variables position in hex file?

    Also, what happens when you power up? Have you tried single stepping through the code to understand what is going on?

    Regards,
    Manoj
  • 0 in reply to Manoj Santha Mohan
    Intellectual 340 points

    Manoj

    1. No part of the code ever erases flash sector A. The flash kernel erases all the sectors except for sector A. Sector A should never, under any circumstances, be erased. Since It contains the code to initiate the bootloading process, it should never be erased. Also, hex file contains no addresses inside sector A. I did this by going into the properties of the C2000 Hex Utility and listing out sections in the linker command file that correspond to sector A addresses. This feature will then exclude those sections from the hex file when ccs is building the hex file. So, hypothetically, if something was erasing flash sector A, it would never startup, even if the bootloader was successful. This doesn't happen. When the bootloader is successful, the application code and the board operate normally just like it would if it was downloaded using a JTAG and CCS.

    I should also note that when the flash kernel is finished erasing, it sends a special character to the host computer indicating it's done erasing the flash. Only then will the host computer attempt to send data that needs to be programmed in flash.

    2. I've checked the flash memory for both the cases when the bootloader is successful and when the error happens. When the bootloader is successful, the flash memory matches what's specified in the project. When the error happens, it shows the inconsistency happens in the address range that's for the cinits. Flash sector A still matches.

    3. The cinits are always in the beginning of the hex file. The starting address and range for the cinits are specified in the linker command file. I've also arranged my linker command file so that the cinits are always first when the hex file is generated. Whenever I rebuild the project, I also manually open the hex to check and make sure this is the case.

    4. Normally on power up, it should wait to detect serial data coming in from a host computer. If nothing happens, it should go on to the application code. However, when the error happens, on power up, it doesn't even attempt to look for serial data. I know this because I activate an LED on my board that stays on during the bootloader wait period. The code waits for seven seconds before going to the application code. However, on power up, the LED doesn't even turn on. There's something going on in  _c_init00 that when the cinit table is not complete, it goes into this state. My guess is that when the terminating zeros haven't been programmed in, it's possible that it interprets a 0xFFFFFFFF as a memory location. When it tries to go to this location, an error occurs since it's obviously not part of the memory map. I don't have the source code for rts2800_fpu32, so I can't say for sure. However, I do have access to rts2800_bl (from the controlSUITE) and it looks like based on the assembly code for boot28.asm this might be possible.

    5. There's no way to single step through this when the error happens. I've tried multiple times, and it doesn't seem possible. Even when I put it in wait boot, all CCS will allow me to do is examine the flash memory. I'm unable to step through the code.

    Based on all of this I think there might be two work arounds:

    Option 1: In the flash kernel, after erasing sectors B-H but before it starts loading the cinits, add in zeros in a memory range that occurs just after the memory range for the cinits. That way, even if the cinits don't finish loading, then boot routine will still see what it thinks are terminating zeros. I can modify the linker command file to make sure no cinits would go where the zeros are located (i.e. don't try to write to non-erased addresses). This should in theory allow the boot to complete and hand control over to the beginning part of the flash code. This will allow the user to still retry the bootloader on startup.

    Option 2: If I could get a hold of rts2800_fpu32, I could modify the cinit portion of the assembly code to not use an address if it's outside the flash memory range (like a non-existent address 0xFFFFFFFF). I could then use this library instead of the normal rts2800 library.

    Syed 

  • 0 in reply to Syed Hasan42
    Intellectual 340 points
    Manoj

    I forgot to mention that I'm in the process of testing option 1. If you have any other suggestions based on what I mentioned here, please let me know.

    Syed
  • 0 in reply to Syed Hasan42
    TI__Guru 55700 points
    Syed,

    If you are able to connect to the device you should be able to single step through the code. What is the problem you are seeing?

    Regards,
    Manoj
  • 0 in reply to Manoj Santha Mohan
    Intellectual 340 points
    Manoj

    The only way I can connect to the device is by putting it into wait mode. Once I do that, I can see the contents of flash, but CCS won't allow me to step through the project (those buttons are greyed out and disabled). I'll try this again to be sure, but this happened to me at least five times.

    The problem I'm seeing is what I described above: if the download is interrupted during the loading of the cinits, then when I power cycle the device, it won't allow me to reattempt my bootloader. It also won't allow me to connect to it using the JTAG and ccs without manipulating the GPIO pins to put it into some other state besides GetMode. However, if I interrupt the download to flash at any other point, I'm still able to reattempt my bootloader after a power cycle.

    Syed
  • 0 in reply to Syed Hasan42
    TI__Guru 55700 points
    Syed,

    You shouldn't have any problems connecting the device if you aren't programming any CSM passwords (ie. when the last eight locations of flash 0x3F7FF8 - 0x3F7FFF are all 0xFFFFs). Also, in your earlier messages you did confirm that sector-A is never erased and never corrupted irrespective of whether you see cinit error. So, if your application code which is looking for specific character using SCI is programmed in SectorA, you should be able to re-boot / re-program without any issues. So, clearly we are missing some critical information here.

    Are you absolutely sure that device gets powered up right? Also, which version of CCS are you using? Because on CCS7, my debugger buttons aren't greyed out when the device is secure.

    Regards,
    Manoj
  • 0 in reply to Manoj Santha Mohan
    Intellectual 340 points

    Manoj

    You're correct, the code that looks for the special character is only in sector A. However, prior to that, the boot28.asm runs. Looking at the code from rts2800_bl from controlSUITE, if there are no terminating zeros, then boot will keep trying to load variables into RAM.

    Since the cinits are loading from a sector that's outside of A, it's possible that all the address have FFFF in them instead of actual addresses (FFFF is located in address locations where the contents have been erased). Furthermore, it's possible that no terminating zeros are present because a communication loss happened between the erase and the programming of the terminating zeros. Therefore, in the case where the erase function for sectors B-H are successful but the cinits haven't been loaded (and crucially no terminating zeros), you could have a serious problem.

    In order to test this theory out, I tried option 1 from my previous comment. Here, I put zeros in the bottom 0x200 addresses of the memory range that I specified in my linker command file. To be more specific, my cinits start at 0x3D8500 and the range is specified for 0xA00. In the flash kernel, after the erase function is successful, I programmed in zeros starting at address 0x3D8D00 and ending at 0x3D8F00. Only when this is complete, the firmware will send a character to the PC indicating that it's ready for data. The PC application then starts sending data (cinits first). It's at this point that I interrupt communication.

    Now, when I cycle power, I'm able to restart my bootloader. Also, I'm able to connect to the board using my JTAG port and CCS (if I so choose to do so).

    I think this pretty conclusively proves that if there are no terminating zeros for the cinit table (which could conceivably happen if the programming is interrupted at the right time), then when the TMS320F28069 is power cycled, there's an error. Again, this is likely because rts2800 interprets 0xFFFFFFFF as an actual address which causes an error.

    So basically, sector A and the initial code that looks for a character can be fine. However, rts2800, which runs before this, is sensitive to the consistency of the cinit table (which isn't in sector A). This can cause a failure.

    Based on this, it seems like if I can go into boot28.asm and add a few lines to check for address 0xFFFFFFF (and ignores it if it finds it), and stops if it reaches then end of the flash memory (if no terminating zeros are found), then this could solve my problem.

    Is there source code available for rts2800_fpu32? All I'm able to find is rts2800_bl.

    Finally, I'm using CCS6.2.

    Syed

  • 0 in reply to Syed Hasan42
    TI__Guru 55700 points

    Syed,

    Source file for rts2800_fpu32 can be found in below path:-

    <ccsv6>\tools\compiler\Latest-compiler-version\lib

    Regards,

    Manoj

  • 0 in reply to Manoj Santha Mohan
    TI__Guru 55700 points

    Syed,

    I got confirmation from software team here that you can modify boot28.asm. Please follow the procedure mentioned in the link below.

    Regards,

    Manoj

  • 0 in reply to Manoj Santha Mohan
    TI__Guru 55700 points
    Syed,

    Can I close this thread? I believe you were able to get around the cinit problem.

    Regards,
    Manoj
  • 0 in reply to Manoj Santha Mohan
    Intellectual 340 points
    Manoj

    Yes, please go ahead and close this thread. I marked the explanation about modifying the rts2800 library as the solution in case anyone else in the future runs into the same issue.

    I implemented this change and got it to work. The only thing I want to add is that the rts2800 library will need to write to a special value to an auxiliary register that indicates whether or not the cinit correctly initialized before it moves on to main. Main will then examine this register and determine whether to stay in the bootloader or move on to the application code.

    Syed