MPC5775E Flash Programming exception

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

MPC5775E Flash Programming exception

Jump to solution
1,253 Views
latheef
Contributor III

All, 

This is continuation of the Solved: Re: Boot Application for MPC5775E - NXP Community.

I have now my boot application allocated to the Block0 of 256K sectors.ie 800000 - 83FFFF.

latheef_0-1667325374955.png

My application now starts from 840000.

I am using the S32DS processor expert and below code for  erasing 15 blocks as one block is where I am executing from

Unlock the sector ->

ret = FLASH_DRV_SetLock(C55_BLOCK_256K_FIRST, 0x8000FFFFU);

/* Erase block */

blockSelect.lowBlockSelect = 0x0U;
blockSelect.midBlockSelect = 0x0U;
blockSelect.highBlockSelect = 0x0U;
blockSelect.first256KBlockSelect = 0xFFFF0000U;
blockSelect.second256KBlockSelect = 0x0U;
ret = FLASH_DRV_Erase(ERS_OPT_MAIN_SPACE, &blockSelect);

The erase looks ok, but when I program the flash I get exception IVOR1

Code is below

ret = FLASH_DRV_Program(&pCtxData,0x00840000,size,from);

Exception as below, with Instruction fetch error bit set in the MCSR register.

latheef_1-1667325779230.png

 

 

latheef_2-1667325787596.png

@lukaszadrapa please help!

 

1 Solution
1,219 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi @latheef 
you are right, in case of MPC5 devices, the flash operations are not launched from RAM. This is the case of SDK for S32K devices, here it is different. Sorry, I'm jumping between these devices a lot.
IVOR14 means that you are jumping to area which is not covered by MMU. My recommendation is to step the "start();" command in asm instructions and check the core registers to see where it jumps exactly (if it is expected address).
Because it obviously jumps to some wrong address, application is not executed at all, so IVPR is not updated by the application and this exception takes vector from the bootloader.
Regards,
Lukas

View solution in original post

6 Replies
860 Views
claudioe
Contributor I

This topic helps us a lot, and is exactly what we were trying to develop.

A bootloader at same address and application too.

1,226 Views
latheef
Contributor III

 

@lukaszadrapaThanks for your pointer, I have fixed the issue now by moving the Erase and Prog codes to RAM as below. Also some of my  functions too to make it work when the erase is in progress.

__attribute__ ((section(".code_ram"))) status_t FLASH_DRV_Program(flash_context_data_t * pCtxData,
uint32_t dest,
uint32_t size,
uint32_t source) __attribute__ ((longcall));

Now I am able to program and confirmed it by checking the CRC32 but executing the application is failing with IVOR14 and it is pointing to the exception table from boot  as shown below

start = (void (*)(void))(*(uint32_t *)(0x00840000+ 0x400));
start();

latheef_0-1667564646722.png

latheef_1-1667564736658.png

 

1) Could you please let me know why I getting exception IVOR14 wuth SRR0 pointing to a weird address?

2) Why is the exception table from boot invoked when I am excecuting the App?

Thanks!

 

1,213 Views
latheef
Contributor III

Below is the correct address to execute the App and now its ok.

start = (void (*)(void))(*(uint32_t *)(0x00840000+ 0x4));
start();

0 Kudos
1,220 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi @latheef 
you are right, in case of MPC5 devices, the flash operations are not launched from RAM. This is the case of SDK for S32K devices, here it is different. Sorry, I'm jumping between these devices a lot.
IVOR14 means that you are jumping to area which is not covered by MMU. My recommendation is to step the "start();" command in asm instructions and check the core registers to see where it jumps exactly (if it is expected address).
Because it obviously jumps to some wrong address, application is not executed at all, so IVPR is not updated by the application and this exception takes vector from the bootloader.
Regards,
Lukas

1,240 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi @latheef 

are interrupts disabled? The erase/program functions are launched from RAM in the drivers but if there's an interrupt accessing the flash, it can fail.

Your bootloader and start of your application are all in partition 6, so I guess this is Read-While-Write problem.

lukaszadrapa_0-1667401913002.png

So, as a first step, I would like to disabled interrupts.

Regards,

Lukas

1,230 Views
latheef
Contributor III

@lukaszadrapaI checked the flash  driver code and it is not coded to be executed from the RAM. When run in Debug Ram mode it all work well.

I could see there is section .code_ram in the linker script, but not used. 

latheef_0-1667473628701.png

I have to erase 15 App sectors and each erase takes 1 second each, but I need to handle the UDS session and send the can message in between to make the UDS tool happy. Do I need to load all the code (including the S32DS CAN Driver code ) to RAM when erasing/programming is going on? If so how do I do it?

Thanks,