Quantcast
Channel: EngineerZone: Message List
Viewing all articles
Browse latest Browse all 36216

Re: BF561: Crash during initialization of C-runtime

$
0
0

I'm still struggling with this problem. I have identified a way to recreate it as simply as possible:

 

Create a new project for the BF561. Do not enable startup code/LDF generation. Select "Add source file with default main() function"

 

Now, if you add the code

*(int*)0xfeb12000=1;

To the main() function, you will get the crash. The crash occurs no matter if CPLB is enabled or not in compiler settings.

 

I realize that 0xfeb12000 is in core B's part of the shared L2 memory in the default LDF. However, if you change this, the crash still occurs.

I changed the definition of the L2 memory sections to

 

MEM_L2_SRAM_ICC       { START(0xFEB00000) END(0xFEB0041F) TYPE(RAM) WIDTH(8) }
#if defined(COREA)  MEM_L2_SRAM_UNCACHED  { START(0xFEB00420) END(0xFEB0220F) TYPE(RAM) WIDTH(8) }  MEM_L2_SRAM           { START(0xFEB04000) END(0xFEB17FFF) TYPE(RAM) WIDTH(8) }
#endif /* COREA */

#if defined(COREB)
  MEM_L2_SRAM_UNCACHED  { START(0xFEB02210) END(0xFEB03FFF) TYPE(RAM) WIDTH(8) }  MEM_L2_SRAM           { START(0xFEB18000) END(0xFEB1FFFF) TYPE(RAM) WIDTH(8) }
#endif /* COREB */

 

Here, MEM_L2_SRAM end has been changed from 0xFEB11FFF to 0xFEB17FFF for Core A, and MEM_L2_SRAM start has been changed from 0xFEB12000 to 0xFEB18000.

The error still occurs though.

 

Also, this has nothing to do with the absolute addressing used in the statement, the same occurs if you add this to the code:

above main:

#pragma section("L2_sram")
volatile char array_to_take_up_space[57344];
#pragma section("L2_sram")
volatile int test=0;

 

In main:

test=1;

Viewing all articles
Browse latest Browse all 36216

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>