flash two version apps on the same microcontroller

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

flash two version apps on the same microcontroller

3,971 Views
joao_ribeiro
Contributor IV

Hello,

We are using the MK64FN1M microcontroller and we are trying to have the ability to flash two versions of the same app , remotely, into the program memory. The ideia is to prevent the device to be stuck if the flashing process goes wrong on one part of the memory having always the other half with an older version.

We are using an ethernet bootloader and we already can flash both parts of the memory and run the app from one or the other, but never having them both on memory or having the ability to switch from one to the other, or reflash them.

We must be doing something wrong on the memory partition , but I cant figure out what. Here is our partition :

Block 1 

joao_ribeiro_0-1640800757353.png

with SCB->VTOR = 0xF000 and when flashing, at the bootloader, the erase goes from 0xf000 to 0x7A000 and the start address is 0xF1D5;

Block 2

joao_ribeiro_1-1640800921333.png

with SCB->VTOR = 0x7A000 and when flashing, at the bootloader, the erase goes from 0x7A000 to 0xF4240 and the start address is 0x7A1D5;

 

Can you please share some info on this idea.

Thank you for the help

Regards

0 Kudos
Reply
6 Replies

3,882 Views
joao_ribeiro
Contributor IV

Hi @ErichStyger  and @jingpan ,

Thank you very much for the help . I will try this tool in order to see if I find the issue.

But in the meanwhile I am still struggling to find the reason for block 2 app not being able to access the configuration part of memory shared with the bootloader on the 0xFE000 . Block 1 app is able to do so.

Thank you for the help.

I will continue trying to find the issue and I if do so, I will let you know.

Regards

 

0 Kudos
Reply

3,942 Views
joao_ribeiro
Contributor IV

Hello,

I think I have managed to find one of the issues so far: I did managed to flash both apps in memory and switch between each other. It seems that I had a large app that was not fitting in half a memory, so when I reduced the size of it, it could be flashed and switched between apps.

So far so good, but something is still wrong. While using the app that is in the block 2 I cant access part of the shared memory with the bootloader for configuration. But if in the app on block 1 I can still change the configuration parameters on the bootloader shared memory at the address 0xFE000 . I need to config it via the app, so that the bootloader behaves differently on the next reset. 

I must be doing something wrong with the correct position of the memory, but I cant figure out what is going wrong.

Can you please share some information, or a memory structural info about this topic?

Thank you

Regards

0 Kudos
Reply

3,928 Views
jingpan
NXP TechSupport
NXP TechSupport

Hi @joao_ribeiro ,

Do you mean the share memory is in block 2 and bootloader can't read the data in this share memory? Does the data really there or be covered by some error? You can use flash tool to read them out and compare.

 

Regards,

Jing

0 Kudos
Reply

3,918 Views
joao_ribeiro
Contributor IV

Hi @jingpan ,

Thank you for the help and concern.

I am sorry if I was a bit confusing on my last post. With this image I intend to clarify the idea that I have for the memory 

 

joao_ribeiro_0-1641293771243.png

So I can jump from block 1 and block 2 having app 1 and app 2 running well, so the bootloader can point to 0xF1D5 and also to 0x7A1D5 without any issue. Although when I try to change the bootloader's configuration that is in the 0xFE000 address I can only have success if I am running the block1 and not the block2. As if the app in block 2 could not reach the memory at the address 0xFE000.

Using a flash tool could be a good way to find more about the issue, you are right. Can we recover the entire memory with the MCUXpresso IDE?

Thank you for the help 

Regards 

 

0 Kudos
Reply

3,895 Views
ErichStyger
Specialist I

Hi @joao_ribeiro ,

>>Using a flash tool could be a good way to find more about the issue, you are right. Can we recover the entire memory with the MCUXpresso IDE?

do you mean storing the memory in a file or something like that?

You can do that with the MCUXpresso IDE: there is an export functionality here:

ErichS_0-1641384323877.png

 

Or see https://mcuoneclipse.com/2012/05/04/dump-my-device-memory/

Other than that, the IDE comes with the SEGGER/J-Link tool. So if you use the SEGGER firmware with your board, than you can use the J-Flash lite to dump the memory too.

I hope this helps,

Erich

3,902 Views
jingpan
NXP TechSupport
NXP TechSupport

Hi @joao_ribeiro ,

No, MCUXpresso hasn't this function. You can use other tool.

 

Regards

Jing