Memory corruption on calling init_can

[rkemp]

I'm using an LPC11C14 and have a problem where if I call init_can it writes to a memory location I wouldn't expect.

I can reproduce this in the sample ccan_rom and have attached the c file which shows this.

( i changed the targets to 11C14 when running this).

In this file I added a global 256 byte buffer, memset it to 0 and can see that calling init_can writes to bytes 105 and 106 of my array.

Any help would be very much appreciated.

[Habib_MS]

Hello @rkemp,

In order to support you better, could you please provide the following details?

-Which IDE are you currently using?

-Regarding your comment "it writes to a memory location I wouldn't expect":

    What memory location were you expecting?
    Where is the data actually being written?
    What values did you expect to be written?
    What values are currently being written instead?

-When you run the example without any modifications, do you see any output?

BR
Habib

[rkemp]

MCUXpresso 24.12

I wouldn't expect a call to can_init to write to any of the heap memory.

As I mentioned, data (0xff) is being written to bytes 105 and 106 of the temp array. This is not the behaviour i would expect when initialising the can interface. I expect no writes to the temp array other than the memset that initialises it all to 0's.

If I run the example without modifications it behaves as expected. I get a can message being sent, and I can receive can messages.

An interesting note, running the example without modifications, calling init_can writes to the same memory locations as when I add my temp array (using the LPC link 2 to debug).

[Habib_MS · Accepted solution]

Hello @rkemp,
In the chapter 17.4.1 called "Calling the C_CAN API" in the RM, the following is mentioned:

"On-chip RAM from address 0x1000 0050 to 0x1000 00B8 is used by the CAN API. This address
range should not be used by the application. For applications using the on-chip CAN API,
the linker control file should be modified appropriately to prevent usage of this area for
application’s variable storage."

It could explain that is currently writing in your buffer, please make sure that your buffer is not in this RAM area. 
BR
Habib