ARM-CGT: The problem of .const section of CM compiler.

I can only think of one reason why you see the error diagnostic from the linker.  There must be a single source file that has a very large .const input section.  Larger than 0x8000 bytes.  Is this the case?

At the same time, there is another detail to consider.  These memory ranges ...

Luke Chen said:

CMBANK0_SECTOR7_0 : origin = 0x00240000, length = 0x00008000
CMBANK0_SECTOR7_1 : origin = 0x00248000, length = 0x00008000

... are adjacent.  There might be some hardware based reason to keep them separate in the linker command file.  But if there isn't, then combine them together into one memory range.

Thanks and regards,

-George

Hi George,

In our original CM .cmd file, we define the flash sector is 0x10000 in length as below,

CMBANK0_SECTOR7_0 : origin = 0x00240000, length = 0x00010000

However, according to boot table format in Assembly Language Tools User's Guide, the data block size is 2-byte(maximum is 0xFFFF) in length, so this flash sector length will cause hex tool generating incorrect hex file(.txt file) for SCI flash kernel, this is the reason I suggest my customer splits flash sectors into two smaller portions and avoid the data block size limitation, is this a correct method?

So another question is that what's the maximum flash sector length for CM hex tool generating correct hex file for SCI flash kernel? Is it 0xFFF0, since 0xFFF0 is less than 0x10000 and 128-bit aligned?

If we have another method for hex tool generating correct hex file for SCI flash kernel even the sector length is equal to or lager than 0x10000, then we can ignore the .const section problem, do we have the method?

Thanks and regards,

Luke

All of the questions in your last post are related to how the bootloader works.  Unfortunately, I do not know any details about the bootloader, and so I am unable to be helpful.  

But what about this question I asked ...

George Mock said:

I can only think of one reason why you see the error diagnostic from the linker.  There must be a single source file that has a very large .const input section.  Larger than 0x8000 bytes.  Is this the case?

Have you investigated to see whether one source file supplies a very large .const input section?  Depending on what you find, we might be able to break it up into smaller pieces that can be split across multiple memory ranges.

Thanks and regards,

-George

Luke,

Our bootloader expert confirmed that the ARM hex tool splits the section for block size more than 0xFFFF.  Since this is a 128-bit aligned split (assuming), it may not cause an unaligned block.  With the latest SCI flash kernel that you received, try loading the hex output that is generated with the linker cmd that has the original length as 0x10000.  

If that still causes the issue, please work with George to break up the .const input section as needed.  

Thanks and regards,

Vamsi

Hi George,

You are right, in my customer's project, there is one big single .const section input more than 0x8000. I believe that this question is related to the behavior of hex tool, not bootloader.

Hi Vamsi,

I understand hex tool is able to generate correct hex file for block size more than 0xFFFF without problems, for example, generate intel hex or TI-TXT hex file.

However, we use below boot options command generating hex(.txt) file for SCI flash kernel. Please check Assembly Language Tools User's Guide, according to the boot table format, the block header(Block size in number of bytes) is 2-byte in length. So hex tool will generate incorrect hex file for SCI flash kernel if the block size more then 0xFFFF, this is the reason I ask my customer to split flash sector into two smaller portions.

"${CG_TOOL_HEX}" "${BuildArtifactFileBaseName}.out" -boot -a -gpio8 -o "${BuildArtifactFileBaseName}.txt"

Please help to check if there is any other ways hex tool generating correct hex file for SCI flash kernel, maybe with certain parameter settings. When generating boot option hex file, is it possible hex tool splits block data into smaller pieces automatically when block size is more than 0xFFFF?

Thanks and regards,

Luke

Luke,

I think the hex tool understands the -boot option and hence splits the input section and generates a max block of 0xFFFF.  Meaning, it will not generate an incorrect hex file for flash kernel and instead just splits a big input section in to multiple (2 or more as necessary) blocks as needed to keep the length under 0xFFFF.  George, do you agree?

If you think it is not the case, please provide an example to reproduce/prove the case where the hex tool outputs an incorrect hex file for the kernel.  This will help the compiler team to reproduce and fix the issue.

Thanks and regards,

Vamsi

Vamsi,

I have further evaluation and you are right, hex tool really splits data block when data size is more than 0xFFFF, please refer to below details.

To reproduce this problem, you can import one CM example project, and use fill method as below,

CMBANK0_SECTOR7_0 : origin = 0x00240000, length = 0x00010000, fill = 0xAA55BB44

Use below -boot option and check the .txt file generated.

"${CG_TOOL_HEX}" "${BuildArtifactFileBaseName}.out" -boot -a -gpio8 -o "${BuildArtifactFileBaseName}.txt"

From below pictures, you can see hex tool generates the last byte at the end of data block, not create a new data block.

Use above .txt file hex tool generated for SCI firmware update, you will get below error message from SCI flash kernel.

Please advise your comments on this situation, how can we solve this problem?

Thanks and regards,

Luke

Vamsi,

I conduct further evaluation, check whether or not CPU1 also has this kind of problem. I combine flash sector 8 and 9 so that length is equal to 0x010000.

FLASH8_9           : origin = 0x0A8000, length = 0x010000, fill = 0xAA55

Build project and generate hex file for CPU1 flash kernel, below is error message, CPU1 has this kind of problem.

Based on the test results of CPU1 and CM,  I believe that CPU2 will also has this problem.

Is there anything I am doing wrong? Please advise how to solve this problem, thanks for help.

Regards,

Luke

Luke,

As I mentioned to you in reply to your offline email on March 15th, it is the same issue that I quoted for C28x hex tool (EXT_EP-10175) -> Your above CM kernel output screenshot confirms the same.  ARM Hex utility, when splitting a section as required by the bootloader, ignores the section alignment for the later block of the split.

CM Flash kernel did not program at address 0x24FFFF since the hex tool split the section at a length (0xFFFF).  Meaning, the block starts at 0x240000 and ends at 0x24FFFE.  The next address is 0x24FFFF - This is not an aligned address.  Meaning, the Hex utility did ignore the alignment request from the linker where we used ALIGN().  

Your C28x kernel snapshot is also showing the same as I mentioned earlier.  This is what I have been explaining to you offline: Hex utility may not skip any, but it is definitely ignoring the alignment after a skip.

Let us wait for George to confirm.

Thanks and regards,
Vamsi

To avoid ...

Vamsi Gudivada said:

the Hex utility did ignore the alignment request

We need to split the .const output section so the hex utility does not see any sections of size greater than 0xffff.  I think we need to limit the size of the memory ranges involved to 0xfff0, so that the start of each memory range is aligned to an 16-byte boundary.  I'd appreciate if Luke or Vamsi would confirm that.  For now, I presume this is correct.

Regarding ...

Luke Chen said:

in my customer's project, there is one big single .const section input more than 0x8000

Is it bigger than 0xfff0 bytes?  If so, for that source file, please follow the directions in the article How to Submit a Compiler Test Case.

Thanks and regards,

-George

Luke,

Since George said "To avoid": I take this as confirmation that the ARM hex utility is skipping the ALIGN() request for the later split. 

Also, please confirm to George if the big single .const is more than 0xFFF0 bytes.

George,

We can limit the memory length size in the linker command file by splitting at 0xFFF0 if needed for this case - I think you are asking this so that the hex utility can start the next block at 128-bit (16-byte) boundary -> Is this what you are asking us to confirm?  Please clarify.  If you confirm that it would cause the hex tool to generate the next block on 16-byte boundary, then yes, we can ask the customer to do the same. 

Thanks and regards,

Vamsi      

This description of the problem ...

Vamsi Gudivada said:

CM Flash kernel did not program at address 0x24FFFF since the hex tool split the section at a length (0xFFFF).  Meaning, the block starts at 0x240000 and ends at 0x24FFFE.  The next address is 0x24FFFF - This is not an aligned address.  Meaning, the Hex utility did ignore the alignment request from the linker where we used ALIGN().  

... is correct.  

The workaround a variation on what is described in this forum post.  In that forum thread, the linker command file is for a C28x device, where addresses are counted in terms of 16-bit words.  In the TI ARM linker command file, addresses are counted in terms of 8-bit bytes.  So, when the memory range is split into pieces, each of those pieces must be aligned to an 16-byte address.  This means the maximum length of any memory range is 0xfff0.  Note lengths smaller than 0xfff0 are OK, as long as they are aligned to 16-bytes.  Otherwise, adapt that example to your situation.

Thanks and regards,

-George

Vamsi and George,

The size of customer's single .const input is 0x8448, I understand this problem can be solved by adjusting sector length.

My understanding is that for SCI upgrade hex file generation, the maximum single sector length is 0xFFF8 for C28x and 0xFFF0 for CM, is it correct?

If this is the case, customers should not use below method combining sectors together if they want to use SCI upgrade function, right?

CMBANK0_SECTOR4_6 : origin = 0x00210000, length = 0x00030000   /* combine sector 4 - 6 */

Another question is that will we plan to solve this problem on newer version hex tool please?

Thanks and regards,

Luke