repeated writes to iap_entry(command, result) cause hard fault

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

repeated writes to iap_entry(command, result) cause hard fault

1,080 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by williamjsell on Wed Jan 20 16:28:27 MST 2016
I have a FreeRTOS thread which is unblocks every 5ms.  It calls the iap_entry function to extract data from the EEPROM.  Works great for about 10s then hard faults.  There is no call stack context as all the PC register and stack pointer contain garbage.  However, I traced it down to the iap_entry call.  Anyone encountered any problems with the iap?


Thanks
Labels (1)
0 Kudos
Reply
5 Replies

874 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by williamjsell on Fri Jan 22 09:25:38 MST 2016
Thanks, disabling the interrupts during read cured the problem.  I added the interrupt disable to the write side as well, I will test this and post the results on this thread
0 Kudos
Reply

874 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by lpcxpresso-support on Fri Jan 22 03:56:44 MST 2016
If you aren't already, it might be worth trying to disable interrupts around the IAP call.

The other thing to check would be how much stack space you have - particularly as it sounds like this call is being made from a particular FreeRTOS thread. Where is the stack for this thread, and how much space is allocated?

Regards,
LPCXpresso Support
0 Kudos
Reply

874 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by williamjsell on Thu Jan 21 13:01:17 MST 2016
The caller:

ee_section_info_t *GetEEPROMData(SectionTypes sectionIndex)
{
    xSemaphoreTake(eepromMutex, portMAX_DELAY);
    uint8_t *base, *offset, retval = 0;
   
    base = (uint8_t *)ⅇ
    offset = (uint8_t *)SectionPointers[sectionIndex].ptr;

    retval = Chip_EEPROM_Read(offset - base, (uint8_t *)SectionPointers[sectionIndex].ptr, SectionPointers[sectionIndex].size);

    if(retval != 0)
    {
        //generate error
        WriteStatus(STATUS_EEPROM_READ_ERROR, true);
    }
    else
    {
        WriteStatus(STATUS_EEPROM_READ_ERROR, false);
    }
    xSemaphoreGive(eepromMutex);
    return SectionPointers[sectionIndex].ptr;
}

the callee:

/* Read data from EEPROM */
uint8_t Chip_EEPROM_Read(uint32_t srcAdd, uint8_t *ptr, uint32_t bytesrd)
{
    static uint32_t count = 0;
uint32_t command[5], result[4];

command[0] = IAP_EEPROM_READ;
command[1] = srcAdd;
command[2] = (uint32_t) ptr;
command[3] = bytesrd;
command[4] = SystemCoreClock / 1000;

    iap_entry(command, result);


return result[0];
}
0 Kudos
Reply

874 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by williamjsell on Thu Jan 21 10:39:49 MST 2016
I tried shielding off 32 bytes at both the top and bottom of RAM1 and RAM2, but this does not make a difference.  Is there anyone who can help here?  Please!!!
0 Kudos
Reply

874 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by williamjsell on Wed Jan 20 18:19:22 MST 2016
I did find this comment on-line:

"Don't forget to modify the stack pointer in your linker file to not use the last 32-bytes of the SRAM (because it's used by the IAP functions)."

this would explain the crash, but this begs my next question: Which SRAM is it referring to, in the LPC11U68, there is main sram ending at x10008000, and a 2K segment ending at 0x20000800.  Anyone know?
0 Kudos
Reply