TMS320F28379D: Output file for FW download is erroneous

Martin,

Can you attach/post the .map file that gets generated inside the /debug directory(it should be in the same dir as your .out file).  This will tell us if there is something getting allocated intentionally by the linker or this is some artifact of the hex translation.

Best,

Matthew

Hi Matthew,
"A problem well-defined is a problem half-solved". So, thank you for asking about the .map file.
I could see in the .map file that there is this entry:

FPUmathTables
* 0 0001a000 0000081a
0001a000 0000068c rts2800_fpu32_fast_supplement_eabi.lib : FPUmathTables.obj (FPUmathTables)
0001a68c 000000d0 : logtable_f32.obj (FPUmathTables)
0001a75c 000000be : exptable_f32.obj (FPUmathTables)

It corresponds to the linker file:
RAMGS14          : origin = 0x01A000, length = 0x001000

I use an FFT algorithm, hench the FPUmathTables. I assume that it is made so that the algorithms run faster from RAM.
What I don't understand is that this is placed in RAM. I would expect it to be placed in ROM or FALSH and then moved to RAM at runtime.
If the hex file places it in RAM and not in FLASH, how is this recovered after a power cycle?

My problem is solved (as I said) by deleting RAMGS14, RAMGS15 and FLASHA. Then the FPUmathTables are located in my application area in FLASHG or FLASHH. But by placing it there it will probably make the math algorithms run slower.

To solve the problem I assume that I can place it in .TI.ramfunc - located in FLASH but copied to RAM at runtime. For my own code I can just write #pragma CODE_SECTION(myFunction, ".TI.ramfunc"); but how is this done when it is a library of C2000? It is about 2kB of data.

Martin,
Thanks for the thorough response, and glad the .map file helped find what was getting allocated to the RAM.  Your finals statements are correct, for best speed you would want to load to FLASH and run from RAM.

I think there are some examples/docs in the C2000Ware directory that will help with the above.

This path: C:\ti\c2000\C2000Ware_4_03_00_00\libraries\dsp\FPU\c28\examples\fft\  has quite a few examples for F2837x and fft;

You can look at the linkers directly here C:\ti\c2000\C2000Ware_4_03_00_00\libraries\dsp\FPU\c28\examples\common\f2837xd\F2837xD_FPU_RFFT_lnk.cmd

there is assignment of the .lib to the ".econst section", which in turn is mapped to flash. 

There is a separate callout for the twiddle tables with the load/run specifier. It looks like this can be done by .obj level in the library as desired

#if defined(USE_TABLES)
   FFT_Twiddles     : LOAD = FLASHB,
                      RUN  = RAMGS12
                      RUN_START(_FFTTwiddlesRunStart),
                      LOAD_START(_FFTTwiddlesLoadStart),
                      LOAD_SIZE(_FFTTwiddlesLoadSize),
                      PAGE = 1,
  {
     --library=c28x_fpu_dsp_library.lib<RFFT_f32_twiddleFactors.obj> (.econst)
  }

Was econst assigned to RAM before, or was there no assignment for econst?  I'm not sure if I'm correct in assuming libs go to econst always or not, but it seems like that may be the case.

I

Also there is this UG here: C:\ti\c2000\C2000Ware_4_03_00_00\libraries\dsp\FPU\c28\docs\  that goes into some detail on what portion of these libs are in ROM, to help free up some memory as well.

Best,
Matthew

Hi Matthew,
Thank you for your answer. Something came up, so I couldn't try your ideas before now.
I looked through all the FFT examples. I tried to solve it with (more or less) what you were suggesting - it was in another example as well.
.econst was already assigned to the project for FLASH. 

This is my cmd linker file:

FLASHG : origin = 0x098002, length = 0x007FFE
FLASHH : origin = 0x0A0000, length = 0x007FF0
FLASHH_META : origin = 0x0A7FF0, length = 0x000010 // Meta data - Markers, time, data, version and checksum

...

FPUmathTables       : >> FLASHH,           PAGE = 0
MetaData            : >  FLASHH_META       PAGE = 0

...

FPUmathTables : LOAD = FLASHH,
RUN = RAMGS2,
RUN_START(_FPUmathTablesRunStart),
LOAD_START(_FPUmathTablesLoadStart),
LOAD_SIZE(_FPUmathTablessLoadSize),
PAGE = 1

I then add the same code as for ".TI.ramfunc" (memcpy). It is yet to test if I succeed in moving it. I guess the only way is to run the code and check if RAMGS2 has the data pattern as I see in the output hex file. Which brings me to another problem.

I am using the --boot --sci8 --ascii parameters for the C2000 Hex Utility tool. This is all good. But if I only use parameter --intel then my output file looks all different. In my code I have meta data in the last 16 bytes of my flash:

#pragma RETAIN(metaStruct) // Makes sure that compiler doesn't optimise it away if not used in the code
#pragma DATA_SECTION(metaStruct,"MetaData"); // Place it in the code section "MetaData" (see command linker file
const MetaStruct_T metaStruct = { // MAG: This is a dummy to show data missing. Use real version, time etc. for release
.Marker1 = 0x1122,
.Marker2 = 0x3344,
.Time = 0x5566,
.DateDayMon = 0x7788,
.DateYear = 0x99AA,
.VersionMajor= 0xBBCC,
.VersionMinor= 0xDDEE,
.CheckSum = 0xFF00,
};


When I build the code I get this output in my hex file:

:087FF00022446688AACCEE00D1

But if I set the memory width to 8, I get this (as expected):

:10FFE0002211443366558877AA99CCBBEEDD00FF19

I don't understand how default memory width = 16 is useful for anything. But I will not use it anyway. My problem is that when I change the memory width from default 16 to 8 the entire memory section changes too:

Here is the beginning of the hex file with memory width 16:

:020000040009F1
:028000004949EC
:20800800044342497100060A283F49D448498100060A284049D4430F060A284149D442149C

Here is the beginning of the hex file with memory width 16:

:020000040013E7
:04000000490049E08A
:2000100004FE437C421E497671DD005206600A8F28063F024976D4E04806497681DD0052B2

The memory section is moved from FLASHH and FLASHG (0x98000 and 0xA0000) to RAMGS7 and RAMGS8 (0x13000 and 0x14000)
I don't understand this. Because it actually works if I use the parameter -ascii instead of -intel. It is the option -boot  that does the magic, but I don't want/need that option. I guess it is just for that specific upload tool that these data are added.

Why would the memory section move when I only use the -intel parameter?

Thanks in advance

Martin,

I'll need some more time on this one, I'm going to need to get some others looped in who are more familiar with the hex output options.

Best,

Matthew

As a side thought, can you take a look at this app note, to see if it addresses the above concerns, or at least gives guidance on the settings we recommend?

https://www.ti.com/lit/pdf/SPRABV4

Best,

Matthew

Hi Matthew,
Thank you for your reply. The link you sent me was more related to the FW download process, but I have had a look at the Hex Convertion Utility Description (https://downloads.ti.com/docs/esd/SPRU513J/Content/SPRU513J_HTML/hex_conversion_utility_description.html#STDZ0797666). But it doesn't clarify exactly my problem.

Thanks in advance,
Martin

Martin Gamst said:

I am using the --boot --sci8 --ascii parameters for the C2000 Hex Utility tool. This is all good. But if I only use parameter --intel then my output file looks all different.

I don't see where you explain why you need Intel format.  Because the application note Serial Flash Programming of C2000 Microcontrollers never uses Intel format, it is very likely no one has tested the combination of --boot --sci8 --intel.

Martin Gamst said:

Why would the memory section move when I only use the -intel parameter?

I am unable to reproduce this behavior.  Please copy and paste the text of the hex2000 command into your next post.  Do not use a screen shot.  If any command files are used, I need to see the contents of those files.

Thanks and regards,

-George

Hi George,

I was waiting for your reply but I see that I never pressed "Reply", so here my reply comes. Thanks in advance

I don't think I explained why I use the hex format. The reason is that I have other projects where I use this format and I would like to use the same firmware upload method for all of my projects so that I don't have to change my Windows program for upload.
Furthermore, I prefer this format to the Ascii format because the FW file is 3 times smaller. Also, debugging is easier for me because you can see directly at each hex file line to which address the chunks of data belong.
In the end, it is a question of preferences I guess...



hex2000:
Command = "${CG_TOOL_HEX}"
Cmd line pattern: ${command} ${flags} ${output_flag} ${output} ${inputs}
Flags: --boot --sci8 --ascii

For the Intes case, the flags are = --intel

If I add --memwidth=8 to the flags, then all my code is removed from FLASH area 0x98000-0xA7FF8 (FLASH G+H)  to RAM area 0x130000-0x14FFF0 (RAMGS7+8)

There is a pre-build-script that makes an SVN h-file, but it should not have anything to do with the output file. Nopost-build-scripts

Cheers
Martin

Hello,

Please note that it is a local holiday today, hence you should hear a response tomorrow.

Thanks

ki

Unfortunately, I need to see exactly how hex2000 is invoked, after all these variables ...

Martin Gamst said:

Command = "${CG_TOOL_HEX}"
Cmd line pattern: ${command} ${flags} ${output_flag} ${output} ${inputs}

... are expanded.  Copy and paste the text of the hex2000 command from the Console view of CCS.  Do not use a screen shot.  If it uses any command files, I need to see the contents of those files.

Thanks and regards,

-George

Hi George,

Thank you for your msg. I have listed the two scenarios with the hex2000 command from the console window of CCS

I have a pre-build step: ..\spicaStd\CreateSvnInfo.bat (it makes a header file with SVN info in it)

I had a post build step that calculated a checksum to be overwritten in the last 2 bytes of the hex file. But I have deleted that part for this test. The output is the same.

=== mem width 8 ==================================

Building secondary target: "0822047_CurrentSharingMonitoring.hex"
Invoking: C2000 Hex Utility
"C:/ti/ccs1240/ccs/tools/compiler/ti-cgt-c2000_22.6.0.LTS/bin/hex2000" --memwidth=8 --romwidth=8 --intel -o "0822047_CurrentSharingMonitoring.hex" "0822047_CurrentSharingMonitoring.out"
Translating to Intel format...
"0822047_CurrentSharingMonitoring.out" codestart ==> codestart
"0822047_CurrentSharingMonitoring.out" .TI.ramfunc ==> .TI.ramfunc
"0822047_CurrentSharingMonitoring.out" .switch ==> .switch
"0822047_CurrentSharingMonitoring.out" .text ==> .text
"0822047_CurrentSharingMonitoring.out" .cinit ==> .cinit
"0822047_CurrentSharingMonitoring.out" .const ==> .const
"0822047_CurrentSharingMonitoring.out" FPUmathTables ==> FPUmathTables
"0822047_CurrentSharingMonitoring.out" MetaData ==> MetaData
Finished building secondary target: "0822047_CurrentSharingMonitoring.hex"

The first line in the hex file:

:020000040013E7                                                                (note starting from 0x130000)

The last 2 lines in the hex file:

:10FFE000112233445566778899AABBCCDDEEFF0019   (all data is there)
:00000001FF

=== mem width default (16) ==================================

Building secondary target: "0822047_CurrentSharingMonitoring.hex"
Invoking: C2000 Hex Utility
"C:/ti/ccs1240/ccs/tools/compiler/ti-cgt-c2000_22.6.0.LTS/bin/hex2000" --intel -o "0822047_CurrentSharingMonitoring.hex" "0822047_CurrentSharingMonitoring.out"
Translating to Intel format...
"0822047_CurrentSharingMonitoring.out" codestart ==> codestart
"0822047_CurrentSharingMonitoring.out" .TI.ramfunc ==> .TI.ramfunc
"0822047_CurrentSharingMonitoring.out" .switch ==> .switch
"0822047_CurrentSharingMonitoring.out" .text ==> .text
"0822047_CurrentSharingMonitoring.out" .cinit ==> .cinit
"0822047_CurrentSharingMonitoring.out" .const ==> .const
"0822047_CurrentSharingMonitoring.out" FPUmathTables ==> FPUmathTables
"0822047_CurrentSharingMonitoring.out" MetaData ==> MetaData
Finished building secondary target: "0822047_CurrentSharingMonitoring.hex"

The first line in the hex file:

:020000040009F1                               (starting from 0x90000)

The last 2 lines in the hex file:

:087FF0001133557799BBDDFF49    (half of the data missing)
:00000001FF

It looks strange that the hex2000 tool would change the memory area as it is a separate tool. Like a post-build step as I understand it

I am looking forward to hear about your comments.

Thanks in advance

Martin