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.

CSM password

Other Parts Discussed in Thread: UNIFLASH

Hello,

I would like to ask questions about CSM password.

We want to use csm password, so we start playing with it. But during our testing we found out following.

If we program password to our uC, then it is not possible to connect to it with programmer and delete password even if we set correct passwrod in programming utility (Uniflash). Only if we set the uC to Boot Wait Mode  (connect GPIO34 to GND) then it was possible to erase memory with using correct password.

Is this feautre of Piccolo or we are doing something wrong.

Is is possible to clear CSM password from running code if I unlock secured memory by correct CSM password?

Thank you

 

Peter

 

  • Hi Peter,

    I would like you to go through this thread: http://e2e.ti.com/support/microcontrollers/c2000/f/171/t/263295.aspx

    Regards,

    Gautam

  • Peter,

    The behavior you cite is correct.  The CSM will disconnect JTAG as soon as an access to secure memory is made.  You need to connect JTAG and unlock the CSM before this happens.  One method is to use wait boot mode which keeps the processor spinning in unsecure ROM.

    You don't say what processor you are using, but this is discussed in the device System, Interrupt, and Control User's Guide.  For example, for F2803x, SPRUGL8C, p.23:

    PEter Prno said:
    Is is possible to clear CSM password from running code if I unlock secured memory by correct CSM password?

    I'm not sure what you are asking here.  Yes, code could perform the password match flow, but this would create a security breach since the passwords would need to be stored in the code.

    Regards,

    David

     

  • Thank you Gautam.

    Thank you David.

    I need to store my password in code because of bootloader, so I will need to erase and program flash memory.  Of course, How to secure bootload process and encrypt your hex file is another  thing. Maybe  I am wrong, but  I think, that I need to store csm password in my code in secured flash, if I want to update my code by any bootload process.

    But if the uC is secured by password, then you cannot read the flash without correct password. Is this true ? So if I understand correctly than whether you have a passwrod in your code or not, it doesn't matter because, you cannot read the code from flash by any external device until it is locked.

     

    I tried to explain my question more detailed :

    What I would like to do is, to erase sector A including password during programm running, then I will not need to set up Wait Boot mode to reprogram flash with new code by JTAG. This will be helpful for our technicians, who will programm uC with completely new code because we do not have possibility to set Wait boot mode on our device without soldering this GPIO34 pin to ground to set it to low. 

    Of course this operation will be controlled by some external proprietary commands with external password ( not CSM password), that customer doesn't have and will never have.

    I hope, I write it more clear

    Thank you.

     

    Peter

     

  • Hello Peter,

    You should identify which specific device you are using when posting to the forums so people can make sure they give you accurate advice.  I suspect you are using a Piccolo device, but which one I don't know.

    From what you've said in your last post, I believe what you are trying to accomplish is a field upgrade of your software via some boot method that you develop.  JTAG is a problem because it gets disconnected by the CSM logic.  So, let's suppose you use some other serial port as the data access point.  You do not need to unlock the CSM to re-flash the device.  What you do is store the flash algorithms in your program (erase, program, verify).  When the command comes in to re-flash the device, the code copies the pieces it needs to secure RAM and runs from there.  You can stream in encrypted segments of the new code via the serial port, and the code in secure RAM can decrypt them and flash them into the device (after first erasing the appropriate sectors).

    Flash sector A should NEVER be erased because if you loose power in the middle of the re-flashing (or have some other snafu, who knows!), you need sector A intact so you can try again.  Also, once you erase sector A the CSM is no longer locked so a hacker could gain access to the device and any other flash contents that may be present.  Sector A should contain your 'bootloader', which is a self-contained program that checks for a valid main app in the other sectors and transfers control to it.  If main app is not valid, the bootloader enters reflashing mode.

    Regards,

    David

     

  • Hello David,

    I apologize. I use Piccolos  2803x, 2805x,  2806x. Thank you for answer, but probably we do not understand correctly ourselves

    There are two different things, what I was trying to ask, but in both it is about flash programming with using csm password

    1. Upload new code by customer by any serial interface for 2803x

    Customer will upload new firmware by himself. So I developed bootloader, which si placed in sector A. We want to use csm password to lock the flash for reading. You said that I don't need to store csm password in my code for this case.

    Now I am using TI Flash Api for Piccolo, which are stored in Boot ROM. I added library 2803x_FlashAPI_BootROMSymbols.lib. To use this API do I need to unlock  CSM in code or not ? I think yes, because if these functions are executed from ROM, then they are trying to access secured memory from unsecured. Without unlocking csm, it looks like it is not working.  How can I copy these functions for erase, write and verify from Boor ROM to RAM, please ?

     

    2. Reprogramm firmware in our factory in case of some repair or some malfunction

    In case that we will need to reprogramm whole secured flash by any programmer ( not by bootloader ) in our factory, we will need to set Wait Boot Mode. Because of older design of our PCBs, this is not possible now without soldering. we need to solder GPIO34 to gnd to set Boot Wait Mode. We would like to avoid this situation somehow and it is not good for us to use bootloader in such situation in repair process or production. So, that is the reason to erase flash A and csm password, then you can reprogramm it without going to Wait Boot Mode, because it is not secured by flash. Of cource this will be possible only in our factory by some proprietary commands. So we don't need to be afraid about hacking, of course if these prorpietary commands will never leave our factory, but it is another point.

     

    Thank you.

     

    Peter

  • Peter,

    PEter Prno said:

    1. Upload new code by customer by any serial interface for 2803x

    Customer will upload new firmware by himself. So I developed bootloader, which si placed in sector A. We want to use csm password to lock the flash for reading. You said that I don't need to store csm password in my code for this case.

    Now I am using TI Flash Api for Piccolo, which are stored in Boot ROM. I added library 2803x_FlashAPI_BootROMSymbols.lib. To use this API do I need to unlock  CSM in code or not ? I think yes, because if these functions are executed from ROM, then they are trying to access secured memory from unsecured. Without unlocking csm, it looks like it is not working.  How can I copy these functions for erase, write and verify from Boor ROM to RAM, please ?

    If you run the flash API code from secure RAM, you do not need to unlock the CSM in order to erase/program/verify the flash.  You can either copy the APIs from the ROM itself, or incorporate the APIs into your own code in flash and copy them from flash.  I've never copied them from ROM, but I don't see why you couldn't do it.  They are at known addresses, and you could probably use symbols from the 23803x_FlashAPI_BootROMSymbols.lib that you mentioned. Some people would say that copying code from unsecure memory to secure memory and then running that code is a security loophole because a hacker could substitute their own code for the stuff you are copying.  But since in this case you're copying from ROM (and nobody can change the ROM), I think it is safe.

    The appnote SPRA958 contains information on how to setup your code project and code to do the copy efficiently.  You typically add a few items to your linker .cmd file to mark the start and end of the section to be copied.

    http://www.ti.com/mcu/docs/litabsmultiplefilelist.tsp?sectionId=96&tabId=1502&literatureNumber=spra958l&docCategoryId=1&familyId=1414

     

    PEter Prno said:

    2. Reprogramm firmware in our factory in case of some repair or some malfunction

    In case that we will need to reprogramm whole secured flash by any programmer ( not by bootloader ) in our factory, we will need to set Wait Boot Mode. Because of older design of our PCBs, this is not possible now without soldering. we need to solder GPIO34 to gnd to set Boot Wait Mode. We would like to avoid this situation somehow and it is not good for us to use bootloader in such situation in repair process or production. So, that is the reason to erase flash A and csm password, then you can reprogramm it without going to Wait Boot Mode, because it is not secured by flash. Of cource this will be possible only in our factory by some proprietary commands. So we don't need to be afraid about hacking, of course if these prorpietary commands will never leave our factory, but it is another point.

    If you are able to send in 'Proprietary' commands (via some serial port I assume), why couldn't you send in the CSM passwords as well?  Then there is no reason to store the passwords in the flash.  In other words, send in an "Unlock CSM" command, followed by the 8 passwords.

    I suppose you can store the passwords in the flash if you want.  I just don't see the need to do so.

     

    Regards,

    David

  • Hello David,

    Thank you. You help me solved my second question.

    But I ve still not finished the 1. question. I tried to copy code from ROM to RAM with Mem Copy Function. It looks that it works, but I still do not tried to call functions from RAM.

    But I was not able to copy code from ROM to RAM by changes in cmd file. I just use MemCopy Function to copy whole code of Flash API functons from Boot ROM to RAM.  Is this correct way? Or do you now the way how to copy code from ROM to RAM by cmd file, please ?

    I found on another post, that it is not possible to copy API from ROM to RAM.

    http://e2e.ti.com/support/microcontrollers/c2000/f/171/t/170158.aspx?pi269061=1

    Wha is your opinion about this, please ?

    I am little bit confused, if I should still try this way. I want to use API functions from Boot ROM to save a flash memory, because whole Flash Api library is quite big.

    Thank you.

    Peter

  • Peter,

    PEter Prno said:

    I found on another post, that it is not possible to copy API from ROM to RAM.

    http://e2e.ti.com/support/microcontrollers/c2000/f/171/t/170158.aspx?pi269061=1

    Wha is your opinion about this, please ?

     

    The cited thread is quite correct.  You cannot copy the APIs from ROM to RAM because they are linked to run from the ROM addresses they currently reside in.  It was an oversight on my part.  I was quickly answering your post and forgot about this.

    So, you should incorporate the flash APIs into your flash code, and set them up to load to flash but run from RAM in the linker command file as discussed in the API documentation.  Either that, or you will need to unlock the CSM during flash reprogramming and then can use the APIs in ROM.  This of course is a security hole as we've been discussing on this thread.

     

    PEter Prno said:

    Or do you now the way how to copy code from ROM to RAM by cmd file, please ?

    What I meant here was you setup the linker cmd file to LOAD to flash but RUN from RAM for the API section, and to generate symbols you can use in your code to locate the load and run addresses and section length.  You still need to use memcopy() to do the copy in your code.  Since again the ROM APIs are already linked, you obviously cannot do this (which is why you cannot run them from RAM - they're not setup to be relocatable).

    Regards,

    David

  • Hello David,

    Thank you for your answers, I will include API to flash and will not use API in boot rom.

    I just didn't find API library for 2806x in control suite. But I found in another thread, that you will post it there.

    http://e2e.ti.com/support/microcontrollers/c2000/f/171/p/329360/1147268.aspx

    Thank you very much for help.

     

    Peter