Reply by Jeff Brower January 23, 20092009-01-23
Erhan-

> It has been a long time after your last message but I was abroad and so
> busy for a long time. I want to tell you my solution and end this
> subject. I solved the problem again after debugging the bootloader
> code. The bootloader of 5416 sets DROM to 0 and OVLY to 1. When I
> modify the memory map and load my code to the allowed memory
> according to these values the problem is solved.

Thanks for following up. As before, great to hear of your progress. Yes a DROM
conflict makes a lot of sense.

> For C55xx DSP s you can set the pmst value using the options of
> hex500 but you can not set this registers value for c54xx.

Right. Improved bootloader... I can guess TI heard a lot of screaming from their
customers during the old C54xx days.

> For using
> the other memory locations you should write a second small code in
> order to configure the memory before loading your whole code.

Ok so what you're saying is load a small code first, turn control over to it, let it
make settings as needed, then it loads the rest of your code.

> Thank you very much for all your help, your guidance was really
> helpful for me.

Sure. Debugging the bootloader directly is a great way to get at the "truth of the
matter" and find out what's going on. I learned that the hard way many years ago,
glad to share it.

-Jeff
OMAP35x EVM jump-starts low-power apps
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building applications based on the OMAP35x architecture: http://www.DSPRelated.com/omap35x
Reply by erha...@hotmail.com January 22, 20092009-01-22
Hi Jeff,
It has been a long time after your last message but I was abroad and so busy for a long time. I want to tell you my solution and end this subject. I solved the problem again after debugging the bootloader code. The bootloader of 5416 sets DROM to 0 and OVLY to 1. When I modify the memory map and load my code to the allowed memory according to these values the problem is solved.
For C55xx DSP s you can set the pmst value using the options of hex500 but you can not set this registers value for c54xx. For using the other memory locations you should write a second small code in order to configure the memory before loading your whole code.
Thank you very much for all your help, your guidance was really helpful for me.

Erhan
OMAP35x EVM jump-starts low-power apps
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building applications based on the OMAP35x architecture: http://www.DSPRelated.com/omap35x
Reply by Jeff Brower November 30, 20082008-11-30
Erhan-

> Yes, my last message was not fully posted, I think I have sent the message
> without finishing it by mistake and the full message is not posted later.
> I am posting it again :
>
> Hi Jeff,
> Let me explain you the problem in more details. My board has an lcd
> display and I am displaying some information on it. As I mentioned before
> everything works perfectly when I load the code from CCS. But when I boot
> serially using the PIC on another board, again the code runs correctly
> but the information cannot be displayed on lcd. The lcd uses a const
> struct array to hold the character data that is defined as below:
>
> //width, height and code for character
> typedef struct CharacterTag
> {
> int w;
> int h;
> unsigned char *code;
> }Character;
>
> //code for the characters
> const unsigned char Codes[] = {
> 0x3,0x4
> ...
> ...
> ...
> }
>
> //this is the const array used, holds width,height and code for all
> characters
> const Character Alphabet[] = {
> {11,15,(unsigned char *)&Codes[0]},
> {5,15,(unsigned char *)&Codes[22]},
> ...
> ...
> ...
> }
>
> This array is corrupted when dsp is booted serially. I am now checking
> the array value at the beginning of my main method and showing whether
> the array is corrupt or not from leds. How can I debug this situation?
> Can you suggest me a way to debug and learn how this happens?

One quick guess would be that DROM, MC or other bits in the PMST (or other status
registers) are not set correctly prior to your application code trying to access
memory areas affected by those bits. In the bootloader, there should be a fragment
of code that runs just after the serial boot process gets started, preparing the chip
for subsequent memory accesses that may be needed. Hex500.exe has options for this
when you generate the .rom file. You can single-step through the bootloader code, as
you did before, to see if what you need to happen with PMST et. al. is actually
happening.

> I realized that when I do not use a gel file in my project same
> condition sometimes happens when I load from CCS also.

In your .gel file below, there is a function C5416_Init() -- but you don't show the
Gel source for it. What does this function do? Does it set PMST bits?

> Can I call Gel init functions from c file? Maybe this can help.

Gel functions are only callable by the CCS IDE -- the idea is to initialize and
prepare DSP access to external peripherals before any actual DSP code runs. Typical
examples include SRAM, SDRAM, Ethernet devices, etc. This makes sense for a "rapid
prototype" development environment, where application-specific code may need to be
tested quickly, and board/external init functions may take time to develop.

Gel functions cannot be called from C code directly, but of course you can look at
the Gel source and figure out what's going on, and then do the same thing in your C
code.

-Jeff

> My gel file and linker command file are simple infact;
> The memory initialization part of my gel file is:
>
> OnTargetConnect()
> {
> C5416_Init();
>
> GEL_XMDef(0,0x1eu,1,0x8000u,0x7f);
> GEL_XMOn();
>
> GEL_MapOn();
> GEL_MapReset();
>
> GEL_MapAdd(0x80u,0,0x7E80u,1,1);
> GEL_MapAdd(0x7F00u,0,0x100u,1,1);
>
> GEL_MapAdd(0x0u,1,0x60u,1,1);
> GEL_MapAdd(0x60u,1,0x0020u,1,1);
> GEL_MapAdd(0x80u,1,0x7F80u,1,1);
> GEL_MapAdd(0x08000u,1,0x8000u,1,1);
>
> GEL_TextOut("Gel StartUp complete.\n");
>
> }
>
> And my linker command file is:
>
> MEMORY
> {
> PAGE 0:
> PROG1 : origin = 0x0080, length = 0x7e80
> VECTORS: origin = 0x7f00, length = 0x0100
>
> PAGE 1:
> MMREGS : origin = 0x0000, length = 0x0060
> SCRATCH : origin = 0x0060, length = 0x0020
> DARAM03 : origin = 0x0080, length = 0x7f80
> DARAM47 : origin = 0x8000, length = 0x8000
>
> PAGE 2:
> IO : origin = 0x0000, length = 0x8000
>
> }
>
> SECTIONS
> {
> .text : load = PROG1 PAGE 0
> .cinit : load = PROG1 PAGE 0
> .switch : load = PROG1 PAGE 0
> .startup : load = PROG1 PAGE 0
> .vectors : load = VECTORS PAGE 0
>
> .bss : load = DARAM47 PAGE 1
> .const : load = DARAM47 PAGE 1
> .sysmem : load = DARAM47 PAGE 1
> .stack : load = DARAM47 PAGE 1
> .data : load = DARAM47 PAGE 1
> }
Reply by erha...@hotmail.com November 20, 20082008-11-20
Yes, my last message was not fully posted, I think I have sent the message without finishing it by mistake and the full message is not posted later. I am posting it again :

Hi Jeff,
Let me explain you the problem in more details. My board has an lcd display and I am displaying some information on it. As I mentioned before everything works perfectly when I load the code from CCS. But when I boot serially using the PIC on another board, again the code runs correctly but the information cannot be displayed on lcd. The lcd uses a const struct array to hold the character data that is defined as below:

//width, height and code for character
typedef struct CharacterTag
{
int w;
int h;
unsigned char *code;
}Character;

//code for the characters
const unsigned char Codes[] = {
0x3,0x4
...
...
...
}
//this is the const array used, holds width,height and code for all characters
const Character Alphabet[] = {
{11,15,(unsigned char *)&Codes[0]},
{5,15,(unsigned char *)&Codes[22]},
...
...
...
}
This array is corrupted when dsp is booted serially. I am now checking the array value at the beginning of my main method and showing whether the array is corrupt or not from leds. How can I debug this situation? Can you suggest me a way to debug and learn how this happens?
I realized that when I do not use a gel file in my project same condition sometimes happens when I load from CCS also. Can I call Gel init functions from c file? Maybe this can help.

My gel file and linker command file are simple infact;
The memory initialization part of my gel file is:

OnTargetConnect()
{
C5416_Init();

GEL_XMDef(0,0x1eu,1,0x8000u,0x7f);
GEL_XMOn();

GEL_MapOn();
GEL_MapReset();

GEL_MapAdd(0x80u,0,0x7E80u,1,1);
GEL_MapAdd(0x7F00u,0,0x100u,1,1);

GEL_MapAdd(0x0u,1,0x60u,1,1);
GEL_MapAdd(0x60u,1,0x0020u,1,1);
GEL_MapAdd(0x80u,1,0x7F80u,1,1);
GEL_MapAdd(0x08000u,1,0x8000u,1,1);

GEL_TextOut("Gel StartUp complete.\n");
}
And my linker command file is:

MEMORY
{
PAGE 0:
PROG1 : origin = 0x0080, length = 0x7e80
VECTORS: origin = 0x7f00, length = 0x0100

PAGE 1:
MMREGS : origin = 0x0000, length = 0x0060
SCRATCH : origin = 0x0060, length = 0x0020
DARAM03 : origin = 0x0080, length = 0x7f80
DARAM47 : origin = 0x8000, length = 0x8000

PAGE 2:
IO : origin = 0x0000, length = 0x8000

}

SECTIONS
{
.text : load = PROG1 PAGE 0
.cinit : load = PROG1 PAGE 0
.switch : load = PROG1 PAGE 0
.startup : load = PROG1 PAGE 0
.vectors : load = VECTORS PAGE 0
.bss : load = DARAM47 PAGE 1
.const : load = DARAM47 PAGE 1
.sysmem : load = DARAM47 PAGE 1
.stack : load = DARAM47 PAGE 1
.data : load = DARAM47 PAGE 1
}
Reply by Jeff Brower November 19, 20082008-11-19
Erhan-

> Let me explain you the problem in more details. My board has an lcd
> display on it and I am displaying information when the board runs.
> As I mentioned evrything works perfectly when I load the code from
> CCS but when I boot from the PIC on another board, the dsp code runs
> correctly again but I cannot display the information correctly on
> lcd. The lcd uses a const array to hold the character data that is
> defined as below:
>
> struct AlphabetCharacters
> {
> int width;
>
> }

Is something missing from this text? I don't see an actual mem declaration, just a
struct definition. I don't see use of 'const' keyword.

I can only assume you didn't declare your LCD char data array in such a way that -c
vs. -cr linker option makes any difference, until you show otherwise.

-Jeff
> Changing from load-time init to run-time init is a major change. If the change really took
> effect (did you remember
> to generate a new .hex file to program the external boot ROM?), then system behavior must be
> different. No way can it
> be "the same".
>
> What about that specific C array that you mentioned before that was not initialized correctly?
> Using -c should have
> fixed that. What do you get now? If that array is not correctly initialized, then I suggest
> to zero in on that.
>
> My general debug suggestion is to focus on one specific (hopefully obvious) thing that is wrong
> and get that fixed
> first. Then other problems may clear up, or at least be easier to identify.
>
> -Jeff
Reply by erha...@hotmail.com November 19, 20082008-11-19
Hi Jeff,
Let me explain you the problem in more details. My board has an lcd display on it and I am displaying information when the board runs. As I mentioned evrything works perfectly when I load the code from CCS but when I boot from the PIC on another board, the dsp code runs correctly again but I cannot display the information correctly on lcd. The lcd uses a const array to hold the character data that is defined as below:

struct AlphabetCharacters
{
int width;
}

Changing from load-time init to run-time init is a major change. If the change really took
effect (did you remember
to generate a new .hex file to program the external boot ROM?), then system behavior must be
different. No way can it
be "the same".

What about that specific C array that you mentioned before that was not initialized correctly?
Using -c should have
fixed that. What do you get now? If that array is not correctly initialized, then I suggest
to zero in on that.

My general debug suggestion is to focus on one specific (hopefully obvious) thing that is wrong
and get that fixed
first. Then other problems may clear up, or at least be easier to identify.

-Jeff
Reply by Jeff Brower November 17, 20082008-11-17
Erhan-

> You were right, my linker option was -cr. I changed it to -c now but
> again the problem continues. My program works when I load from CCS
> but it does not work as expected when I boot serially after powering
> off and on. Do you have any other idea?

Changing from load-time init to run-time init is a major change. If the change really took effect (did you remember
to generate a new .hex file to program the external boot ROM?), then system behavior must be different. No way can it
be "the same".

What about that specific C array that you mentioned before that was not initialized correctly? Using -c should have
fixed that. What do you get now? If that array is not correctly initialized, then I suggest to zero in on that.

My general debug suggestion is to focus on one specific (hopefully obvious) thing that is wrong and get that fixed
first. Then other problems may clear up, or at least be easier to identify.

-Jeff
Reply by erha...@hotmail.com November 17, 20082008-11-17
Hi Jeff,
You were right, my linker option was -cr. I changed it to -c now but again the problem continues. My program works when I load from CCS but it does not work as expected when I boot serially after powering off and on. Do you have any other idea?
Reply by Jeff Brower November 12, 20082008-11-12
Erhan-

> Thanks again for the last time. I returned to my project after
> successfully booting the dsp and my code is ready using CCS now.
> My problem is that some part of my code does not work as
> expected when I boot serially but it works fine when I program
> the dsp from CCS. There are no problems for the other parts of
> the code for serial boot case. I realized that when I reset and
> boot the dsp serially after programming the dsp from ccs without
> powering off, evrything works fine. I found that the reason is
> an array which is corrupt when I turn off the power and boot
> serially. Wrong values are read from this const struct array
> after serial boot. What may be the problem? Is it a problem
> caused by wrong initialization of memory map? But I can not
> understand how it works on ccs and not for serial boot?

My guess is that you have the -cr (load-time) Autoinit option set in the Linker. In
that case, CCS would initialize arrays for you when it downloads code, but the
bootloader would not be able to able to handle that. CCS can do this because it
understands the COFF file format used by codegen tools to create the final DSP
executable.

Try the -c option (run-time initialization). If that doesn't work let us know.

-Jeff

PS. There is a good thread about this currently going on the C55x group (look for
subject 'Linker Autoinit Options').
Reply by erha...@hotmail.com October 28, 20082008-10-28
Hi Jeff,
Thanks again for the last time. I returned to my project after successfully booting the dsp and my code is ready using CCS now. My problem is that some part of my code does not work as expected when I boot serially but it works fine when I program the dsp from CCS. There are no problems for the other parts of the code for serial boot case. I realized that when I reset and boot the dsp serially after programming the dsp from ccs without powering off, evrything works fine. I found that the reason is an array which is corrupt when I turn off the power and boot serially. Wrong values are read from this const struct array after serial boot. What may be the problem? Is it a problem caused by wrong initialization of memory map? But I can not understand how it works on ccs and not for serial boot?