TMS320F2800137: motorola Option

thanks

in hex，Why are the addresses not continuous and what is the reason？

youjun zhang said:

Why are the addresses not continuous

That's the default behavior.  In practice, that is what most users want most of the time.  Among other things, it means the hex file is smaller.

To change this behavior, use image mode and the --fill option as described in my previous post.

Thanks and regards,

-George

i used fill option,filled oxffff.

but Why the number of each row is different?What settings or compilations caused?

Unfortunately, using the fill feature does not guarantee each record is the same length, or starts on some address boundary.

Thanks and regards,

-George

I want to know why the number of each row is different?

What settings or compilations caused?

how to solve the probelm?

youjun zhang said:

how to solve the probelm?

My understanding of your problem is incomplete.  But I'm confident there is no solution available from the hex utility.

youjun zhang said:

I want to know why the number of each row is different?

I can shed some light on this question.  Please understand this does not tell you anything you can act on.  These details are incidental to the implementation.  They are not part of the public interface.  That means these details can change at any time, with no notice.  

The hex utility processes the input executable object file one section at a time.  When the next section is processed, a new record is started.  When the data for a section runs out, the current record is terminated, without regard for the length of that record.

Thanks and regards,

-George

hi 

as you said,When the next section is processed, a new record is started

but wrapped  lines in the same sector.

youjun zhang said:

but wrapped  lines in the same sector.

I'm not sure, but I think you mean that sometimes the hex utility starts a new line in the middle of a section.  When the output for one line reaches some limit (around 20 bytes of output), the current line is terminated and a new line is started.  That is the only circumstance where I've seen the hex utility start a new line in the middle of a section.  But even if a new line started in the middle of a section for some other reason, that is not a violation of the Motorola format specification.

Thanks and regards,

-George

hi

Your understanding is correct.

When the output for one line reaches some limit (around 20 bytes of output), the current line is terminated and a new line is started.

this is correct.

but sometimes one line does not  reach the limit (around 20 bytes of output), the current line is terminated and a new line is started.

shown as the pic.

I want to know the reason for this?

The most likely reason is that the current section ended, and the next one started.  This causes a new line to be output in the hex file, even if the two sections are adjacent in memory.

Thanks and regards,

-George

at line 0x823C0 only 4 32bit

next line is 0x823C4 is in the same section.

as you said :The most likely reason is that the current section ended, and the next one started 

this reason is not right.

How do you know the address 0x000823C4 is not the start of a new section?  Check the linker map file.  

But even if it is not the start of a new section, this is still valid Motorola hex format.

Thanks and regards,

-George

the sector 8 is started from 0x00082000,end :0x000823FF,

so the address 0x000823C4 is not the start of a new section.

That table in that screenshot does not say anything about sections.  It describes memory ranges available on a device or system.  To understand the difference between a memory range and a section, please see the first part of the article Linker Command File Primer.  Though that article makes a distinction between the terms input section and output section.  Throughout this forum thread, every time I use the term section, that is the same as the term output section in that article.

Thanks and regards,

-George