TMS320F28069: flash occupying question

The linker has no feature which can force two output sections like .cinit and .econst to be adjacent.  In most cases, the .cinit section requires no alignment and the .econst section requires 2-word (32-bit) alignment.  In such a case, when .cinit is followed by .econst, there is a 1 word hole about half the time.  Put another way, a similar hole must occur in other builds on a regular basis.

Howard Zou said:

They met this problem by adding "switch case" functions in their code

Please ignore this detail.  That caused the .switch section to be larger, which in turn causes the .cinit section to start on a different address than otherwise, and eventually leads to the hole between .cinit and .econst.  But, if not this detail, some other detail will cause the hole.  

Howard Zou said:

the code could not run correctly if .cinit section and .econst section occupy flash memory not consecutively

Are you certain this is the root cause of the problem?  Many other builds have similar holes between initialized sections, and those builds work.

Thanks and regards,

-George

Mock,

we also find that sometimes the memory map doesn't align:

we have 2 project and the only difference is shown below: 

By looking at the memory map the last address occupied is 3e01eb for the left side, 3e01e8

However it doesn't align with the IQMATH last address:

the left side it's 3e01ec>3e01eb(this should be caused by the hole I mentioned in the previous post), the right side is 3e01e8=3e01e8

And the left side project could not run correctly, so we suspect that it's caused by the flash memory occupied doesn't align with the last address shown in IQMATH.

Howard,

As George said, alignment holes shouldn't cause an issue themselves.  The linker will dynamically correct the addresses of function calls, etc as the code size changes.

When the code fails, can you comment on the action on the C2000?  Does the Illegal ISR get called, or the WD timeout, or a wrong calculation? 

Can we also look at the memory reserved for the stack in both cases and make sure it isn't overflowing in the first case?

Best,

Matthew

Matt,

the code fails by stuck in DSP28x_usDelay when we click run after flashing the device:

the memory map for code that could not run is:

N2002ACAPP-NotRun.map

the memory map for code that could run is:

N2002ACAPP.map

Howard,

Can the customer capture the contents of the CPU registers when it is in this function?  Specifically I'd like to see the value of the SP(stack pointer) and RPC registers.  I'm not sure how the code would get stuck in this loop, eventually it will exit once ACC = 0.

Best,
Matthew

Matt,

when the code could not run, the stack pointer is larger than 0x400 as below:

Howard,

Looking at the map file I think the stack starts at 0x400 for both builds, with 0x300 reserved for this.  So I think the SP is reasonable here(well below 0x412).

Would it possible for customer to send both sets of code/source off forum?  Would I be able to run on a LAUNCHXL-F28069M standalone and observe the failure?  I think we are going to have to trace backwards to see what is causing the issue to understand why this is happening.  I don't think the holes are the issue, but whatever is causing the change in mapping is somehow related here.

Best,

Matthew