booting C5416 using standard serial boot method

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 Start a New Thread

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 Start a New Thread

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
} Start a New Thread

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
> } Start a New Thread

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 Start a New Thread

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 Start a New Thread