IVOR1 when copying .data to RAM

Showing results for 
Search instead for 
Did you mean: 

IVOR1 when copying .data to RAM

Contributor III

My program consists of a bootloader and an app.

In the app, when I try to copy the .sdata section from flash to RAM, I get an IVOR1 exception.

If I copy the init_RAM function to my bootloader source code (and replace the linker symbols _etext, _edata, _data, _bss, _ebss) and call it from the bootloader, I don't get an IVOR1 exception.

The bootloader calls an entry-point function in the app, there are no restarts in between.

static void init_RAM(void) {
    uint32_t *pulSrc, *pulDest;

    // Copy data segment initializers from flash to SRAM
    pulSrc = &_etext;
    for(pulDest = &_data; pulDest < &_edata; )   {
        *pulDest++ = *pulSrc++;

    // Initialize bss section to zero
    for(pulDest = &_bss; pulDest < &_ebss; )
        *pulDest++ = 0;

 My Bootentry.S file has code for initializing the SRAM ECC.

#***************************** Initialise SRAM ECC ***************************/
# Store number of 128Byte (32GPRs) segments in Counter
 e_lis       r5, __SRAM_SIZE@h  # Initialize r5 to size of SRAM (Bytes)
 e_or2i      r5, __SRAM_SIZE@l
 e_srwi      r5, r5, 0x7         # Divide SRAM size by 128
 mtctr       r5                  # Move to counter for use with "bdnz"

# Base Address of the internal SRAM
 e_lis       r5, __SRAM_BASE_ADDR@h
 e_or2i      r5, __SRAM_BASE_ADDR@l

# Fill SRAM with writes of 32GPRs    
    e_stmw      r0,0(r5)            # Write all 32 registers to SRAM
    e_addi      r5,r5,128           # Increment the RAM pointer to next 128bytes
    e_bdnz      sram_loop           # Loop for all of SRAM

The content of the MCSR register:


The C55FMC.MCR register:


Does this mean that the IVOR1 exception was not caused by reading from the flash? (When I've had IVOR1 problems with flash reads, then bits in the C55FMC.MCR register has been set).

The content of the 24 bytes .sdata section in flash.


The content in ram for [_data, _edata):


Any suggestions on how to proceed? How can I figure out if this is a problem in RAM or FLASH? I'm working on reducing this down to a program that I can post here for more feedback.

Labels (1)
Tags (3)
3 Replies

Contributor III

I've noticed that pulSrc in my source example above only has the lower two bytes set. So if _etext has the value 0x014c2ea4; then pulSrc gets assigned the address 0x00002ea4. Has anyone experienced this? I'm starting to wonder if it's the debugger that is showing exported linker symbols incorrectly (_data, _edata, _bss ...).

0 Kudos

NXP TechSupport
NXP TechSupport

It looks like that your problem concerning RAM. The init_RAM function provides SRAM clearing.

Perhaps your should compare the init_RAM assemble code and your bootentry.S code.

Have a great day,
Pavel Chubakov


Note: If this post answers your question, please click the Correct Answer button. Thank you!

Contributor III

My problem was caused by this compiler/linker bug: 20744 – [PPC] Incorrect relocation for VLE-instructions 

The bootloader part was compiled with gcc 4.9.4. The app part was compiled with 4.9.2 (it included linking some object files from the bootloader). The handling reloaction  for e_lis caused me much grief. One bit of the register part of the instruction got overwritten which lead to a bug that was hard to track down. The fact that I had had problems with IVOR1 exceptions caused by Flash ECC errors lead me debugging journey down the wrong lane.

But all is well that ends well, and once I built both bootloader and app with the same compiler/linker things works as expected.

0 Kudos