This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

HardKernel after calling IAP

I am trying to read UID value from LPC11xx chip. My code is running ok, until I try to read UID. After that, well after few other things that run on the uC it ends up in HardKernel.
I guess stack overflow or something, but I dont see anything wrong in iap call..

#define IAP_ADDRESS 0x1FFF1FF1

struct iap_commands{
        enum CMD {
                eReadUID = 58
        };
};
unsigned int param_table[5];
unsigned int result_table[5];
typedef void(*iap)(unsigned int [], unsigned int []);
iap iap_entry;


void read_serial_num ()
{
    iap_entry = (iap)IAP_ADDRESS;
    param_table[0] = iap_commands::eReadUID;
    iap_entry (param_table, result_table);
}

It is totally same whether I call this function at the beginning of main or at some other place, it would always end up with HardKernel. Same use case but without call of read_serial_num runs fine.

I am not really near the RAM or ROM limit of uC.

I am using C++. Am I missing some extern "C" somewhere ?

Parents
  • Perhaps you should consider clearing the structure or other fields within it first? Leaving it with random junk, or values unusable by the IAP code may cause it to touch memory that it should not.

    Are there requirements to use specific RAM areas for the parameters? Is the Hard Fault allowing you to determine what exactly faulted? ie the memory address is was trying to touch and the instructions it was using.

    Standard debugging techniques should allow you to determine what is annoying the processor.

Reply
  • Perhaps you should consider clearing the structure or other fields within it first? Leaving it with random junk, or values unusable by the IAP code may cause it to touch memory that it should not.

    Are there requirements to use specific RAM areas for the parameters? Is the Hard Fault allowing you to determine what exactly faulted? ie the memory address is was trying to touch and the instructions it was using.

    Standard debugging techniques should allow you to determine what is annoying the processor.

Children