***** .

Hi Mehul,

It is because there are some flash region in CSC of bank0 is write protected, and it could not be erased when running application program.

You could have a factory reset of the MCU by guide of 7.1 Unlock MCU of MSPM0 MCUs Development Guide (Rev. E) 

Best Regards,

Pengfei

Hi Xie, Thank you. 

yes i have seen this information. upto which address in flash bank 0 is write protected? i mean i am placing my image at address 0x4800 initially. but not able to flash new image at 0x4800 again. in practical use it should be possible to write new image in either of the bank (only exception of write protected region.). what need to do to update / write new image in same 0x4800 location , how to disable this write protection region? does entire bank0 become write protected after first time program? 

Hi Mehul,

Understood. Firstly in the CSC example, the address 0x4000-0x4800 is write protected. 

And I think it is because the bank swap is enabled and the whole running bank is write protected, while another bank is writable and execution protected. Please refer to  4.4.1 Bank Swapping of MSPM0 G-Series 80-MHz Microcontrollers Technical Reference Manual (Rev. B) for more details.

So when using bank swap (default used in CSC example), the updated firmware could only be written to another bank (logic bank1). 

Best Regards,

Pengfei

Hi Xie , It means if bank swap enable i wont be able to write new image in bank0 right? then what to do if i want to change write executable permission ? means if my current running image is in bank1 and i want to update new image in bank0 but eventually bank 0 is having write protection then how I can do that? i referred 4.4.1 section but it was lil bit hard to understand.   

Hi Mehul,

The write permission is determined by bank swap automatically when using bank swap:

- If you the program is running in bank0, then the bank0 could not be erased or written, and the bank1 could be erased and written.

- If you the program is running in bank1, then the bank1 could not be erased or written, and the bank0 could be erased and written.

- No matter you are running at bank0 or bank1, the flash address you are running is from 0x0000-0x40000(for G3519), and you could only erase and program data to 0x40000-0x80000 address.

When using CSC example, in any cases, you could not erase or write the region in address 0x0000-0x4800 in bank0 and bank1 because it is for CSC program. 

Best Regards,

Pengfei

Hi Xie,

Thanks for this clarification. Does CSC perform Image verification every time? or just for the first time? is my understanding correct that for first INITDONE issue image verification gets performed and once INTDONE issue from next power cycle it directly boot  application image rather verify image again.

Hi Mehul,

Actually for each power cycle (after power-on reset), the program will start with INITDONE not issued and the program will go to the image verification.

But there are two cases for image verification:

- If the image is new (get updated), CSC will verify it by signature by ECDSA.

- if the image is not get updated,  CSC will verify it by CMAC tag of the image based on AES, which takes much less time than by ECDSA.

Hi Xie , It means if I disable CMAC verification part and keep only ECDSA verification. then on every time my image verification done using ECDSA only, irrespective of updated image or old image.

Yes. That's right.

In CSC code I am able to find Rollback protection implementation but in document it mentioned that these features not available? is your document outdated? or implementation is not trusted? it creates conflict. Secure Booting User's Guide also mentioned rollback not supported but implemented in code. 

Hi Mehul,

The Rollback protection is achieved in CSC example by flash, to make sure a counter in flash increase only every time.

So it is not a physical monotonic increase .counter achievement for Rollback protection, just an implement by flash. So this is what it means that in future release there may be update to achieve Rollback protection by a physical monotonic increase .counter.

Best Regards,

Pengfei

OK, so Hardware rollback protection is not supported right?

Yes. Currently not supported in CSC example.

Thank you Xie.This clear my doubt.  Another Question what if i want to allow Rollback then? as current image selection criteria is always select high version image. but i want Rollback to lower version then what possible option available to do that?   

You may need to write the same image with a higher version to another bank. 

Otherwise, you could change the bank swap judgement logic by yourself. (Currently it is by checking the image version)

Just to make sure. Dose current version of CSC capable to do roll back to any valid image of lower version.? can you give me some idea how I can achieve this? like swap judgement logic you mentioned. that will be helpfull. 

I know current CSC follows rollback protection but if i disable it then how can i get Roll back done?