Hi,
I am using PIC18F97J60 to boot 5416 using MCBSP0. I have built my boottable
using -v548 assembler option and I am sending this boottable starting from word
0x10AA after resetting the dsp and waiting for XF pin to go low. I worked on
this issue so much and read all the documents including the bootloader
document(spra602) supplied by ti. I think the documentation is insufficient. Can
you tell how to boot the dsp step by step? can you please explain the serial
communication details while booting? Is the clock and data lines active low or
high? at which edge of the clock the data is transmitted? how is the frame sync
signal look like? is it active low or high and is it active during the
transmission of whole word(16 bit in this case) or is it active for a while
before transmission? do you have a figure showing the states? Figure 8 at
spra602 is not clear. Also should I send some dummy clock signals before sending
data? I am now using the data, clock and fsync lines as general I/O pins at pic
in order to adjust necessary timing of these pins and my bootloader code looks
like below. Please help me for this issue. Thank you very much.
void BootDSP(void)
{
int i;
InitSerialData(); //for initialization of PIC I/O ports
ResetDSP();
while (XF== 1) ; //wait
for(i=0; i
{
WriteSerialData(BootCode[i]);
}
}
void WriteSerialData(int data)
{
int i,j;
Data=0;
FSync=1;
Clock=0;
for(i=0; i<16; i++)
{
Data = (data & 0x8000)>>15;
Clock =0;
Clock=1;
FSync=0;
data = data << 1;
}
}
void ResetDSP(void)
{
DSP_RST = 0; // reset pin of DSP is low
delay(1);
DSP_RST = 1; // reset pin of DSP is high
}
booting C5416 using standard serial boot method
Started by ●October 4, 2008
Reply by ●October 5, 20082008-10-05
Erhan-
> I am using PIC18F97J60 to boot 5416 using MCBSP0. I have built my
> boottable using -v548 assembler option and I am
> sending this boottable starting from word 0x10AA after resetting
> the dsp and waiting for XF pin to go low. I worked on
> this issue so much and read all the documents including the
> bootloader document(spra602) supplied by ti. I think the
> documentation is insufficient. Can you tell how to boot the dsp
> step by step?
The TI documentation already explains the step-by-step process in detail. What you need now are better debug methods.
My suggestion is to use CCS to single-step through the 5416 bootloader code. You can follow the bootloader code
instruction-by-instruction (it's in asm) and "see through its eyes" what's going on. For example, first question:
does the bootloader even recognize that McBSP0 boot is happening? If so, what's the first word it receives? Does it
even receive the first word?
The bootloader code is the final word, not TI documentation. The code is "the reality" so that's where your debug
efforts should be focused.
-Jeff
> can you please explain the serial
> communication details while booting? Is the clock and data lines active low or high? at which edge of the clock the
> data is transmitted? how is the frame sync signal look like? is it active low or high and is it active during the
> transmission of whole word(16 bit in this case) or is it active for a while before transmission? do you have a figure
> showing the states? Figure 8 at spra602 is not clear. Also should I send some dummy clock signals before sending
> data? I am now using the data, clock and fsync lines as general I/
> O pins at pic in order to adjust necessary timing of these pins and my bootloader code looks like below. Please help
> me for this issue. Thank you very much.
>
> void BootDSP(void)
> {
> int i;
> InitSerialData(); //for initialization of PIC I/O ports
> ResetDSP();
>
> while (XF== 1) ; //wait
> for(i=0; i > {
>
> WriteSerialData(BootCode[i]);
>
> }
>
> }
> void WriteSerialData(int data)
> {
> int i,j;
>
> Data=0;
> FSync=1;
> Clock=0;
> for(i=0; i<16; i++)
> {
> Data = (data & 0x8000)>>15;
> Clock =0;
> Clock=1;
> FSync=0;
> data = data << 1;
> }
>
> }
> void ResetDSP(void)
> {
> DSP_RST = 0; // reset pin of DSP is low
> delay(1);
> DSP_RST = 1; // reset pin of DSP is high
>
> }
> I am using PIC18F97J60 to boot 5416 using MCBSP0. I have built my
> boottable using -v548 assembler option and I am
> sending this boottable starting from word 0x10AA after resetting
> the dsp and waiting for XF pin to go low. I worked on
> this issue so much and read all the documents including the
> bootloader document(spra602) supplied by ti. I think the
> documentation is insufficient. Can you tell how to boot the dsp
> step by step?
The TI documentation already explains the step-by-step process in detail. What you need now are better debug methods.
My suggestion is to use CCS to single-step through the 5416 bootloader code. You can follow the bootloader code
instruction-by-instruction (it's in asm) and "see through its eyes" what's going on. For example, first question:
does the bootloader even recognize that McBSP0 boot is happening? If so, what's the first word it receives? Does it
even receive the first word?
The bootloader code is the final word, not TI documentation. The code is "the reality" so that's where your debug
efforts should be focused.
-Jeff
> can you please explain the serial
> communication details while booting? Is the clock and data lines active low or high? at which edge of the clock the
> data is transmitted? how is the frame sync signal look like? is it active low or high and is it active during the
> transmission of whole word(16 bit in this case) or is it active for a while before transmission? do you have a figure
> showing the states? Figure 8 at spra602 is not clear. Also should I send some dummy clock signals before sending
> data? I am now using the data, clock and fsync lines as general I/
> O pins at pic in order to adjust necessary timing of these pins and my bootloader code looks like below. Please help
> me for this issue. Thank you very much.
>
> void BootDSP(void)
> {
> int i;
> InitSerialData(); //for initialization of PIC I/O ports
> ResetDSP();
>
> while (XF== 1) ; //wait
> for(i=0; i > {
>
> WriteSerialData(BootCode[i]);
>
> }
>
> }
> void WriteSerialData(int data)
> {
> int i,j;
>
> Data=0;
> FSync=1;
> Clock=0;
> for(i=0; i<16; i++)
> {
> Data = (data & 0x8000)>>15;
> Clock =0;
> Clock=1;
> FSync=0;
> data = data << 1;
> }
>
> }
> void ResetDSP(void)
> {
> DSP_RST = 0; // reset pin of DSP is low
> delay(1);
> DSP_RST = 1; // reset pin of DSP is high
>
> }
Reply by ●October 6, 20082008-10-06
Hi Jeff,
First of all thanks for your answer. I am not so experienced at asm but I tried debugging as your advice.
The bootloader checks IFR for any BSP interrupts, finds that MCBSP0 interrupt is active and jumps to 0xf95d as below
000:F8D1 6101 BITF IFR,400h
0000:F8D3 F930 CC 0f967h,TC
0000:F8D5 6101 BITF IFR,40h
0000:F8D7 F930 CC 0f971h,TC
0000:F8D9 6101 BITF IFR,10h
0000:F8DB F930 CC 0f95dh,TC
code at 0xf95d is:
0000:F95D 7738 STM 0h,38h
0000:F95F 7716 STM 39h,AR6
0000:F961 7711 STM 21h,AR1
0000:F963 7701 STM 10h,IFR
0000:F965 F073 B 0f97bh
saves adresses of MCBSP0 registers and jumps to 0xf97b:
0000:F97B 4881 LDM *AR1,A ->DRR0 is written to A.
0000:F97C F110 SUB #10aah,0,A,B ->Subtract 10aa from A, shift by 0 and write result to B
0000:F97E F84D BC 0f981h,BEQ -> conditional jump if BEQ(B=0)
0000:F980 FC00 RET
at this point it does not jump to 0f981 and continues from next step. A is read as 0 and also adress 0x21 at data memory(DRR0) is 0. I checked the signal from scope and it seems OK. What can be the reason for DSP not reading the data correctly? Thank you.
First of all thanks for your answer. I am not so experienced at asm but I tried debugging as your advice.
The bootloader checks IFR for any BSP interrupts, finds that MCBSP0 interrupt is active and jumps to 0xf95d as below
000:F8D1 6101 BITF IFR,400h
0000:F8D3 F930 CC 0f967h,TC
0000:F8D5 6101 BITF IFR,40h
0000:F8D7 F930 CC 0f971h,TC
0000:F8D9 6101 BITF IFR,10h
0000:F8DB F930 CC 0f95dh,TC
code at 0xf95d is:
0000:F95D 7738 STM 0h,38h
0000:F95F 7716 STM 39h,AR6
0000:F961 7711 STM 21h,AR1
0000:F963 7701 STM 10h,IFR
0000:F965 F073 B 0f97bh
saves adresses of MCBSP0 registers and jumps to 0xf97b:
0000:F97B 4881 LDM *AR1,A ->DRR0 is written to A.
0000:F97C F110 SUB #10aah,0,A,B ->Subtract 10aa from A, shift by 0 and write result to B
0000:F97E F84D BC 0f981h,BEQ -> conditional jump if BEQ(B=0)
0000:F980 FC00 RET
at this point it does not jump to 0f981 and continues from next step. A is read as 0 and also adress 0x21 at data memory(DRR0) is 0. I checked the signal from scope and it seems OK. What can be the reason for DSP not reading the data correctly? Thank you.
Reply by ●October 6, 20082008-10-06
Erhan-
> First of all thanks for your answer. I am not so experienced at asm
> but I tried debugging as your advice.
>
> The bootloader checks IFR for any BSP interrupts, finds that MCBSP0
> interrupt is active and jumps to 0xf95d as below
>
> 000:F8D1 6101 BITF IFR,400h
> 0000:F8D3 F930 CC 0f967h,TC
> 0000:F8D5 6101 BITF IFR,40h
> 0000:F8D7 F930 CC 0f971h,TC
> 0000:F8D9 6101 BITF IFR,10h
> 0000:F8DB F930 CC 0f95dh,TC
>
> code at 0xf95d is:
>
> 0000:F95D 7738 STM 0h,38h
> 0000:F95F 7716 STM 39h,AR6
> 0000:F961 7711 STM 21h,AR1
> 0000:F963 7701 STM 10h,IFR
> 0000:F965 F073 B 0f97bh
>
> saves adresses of MCBSP0 registers and jumps to 0xf97b:
>
> 0000:F97B 4881 LDM *AR1,A ->DRR0 is written to A.
> 0000:F97C F110 SUB #10aah,0,A,B ->Subtract 10aa from A, shift by 0 and write result to B
> 0000:F97E F84D BC 0f981h,BEQ -> conditional jump if BEQ(B=0)
> 0000:F980 FC00 RET
>
> at this point it does not jump to 0f981 and continues from next step.
> A is read as 0 and also adress 0x21 at data memory(DRR0) is 0. I
> checked the signal from scope and it seems OK. What can be the reason
> for DSP not reading the data correctly? Thank you.
That's excellent work -- you're on the right track for sure. It appears to me that
McBSP0 simply received the wrong word. You can display the contents of acc A and
find out what actually was received. Is the bit order reversed? Is a bit missing?
The value is shifted by one or more bits? There are many things to check, including
clock polarity, frame sync delay, lsb vs. msb order, etc.
-Jeff
> First of all thanks for your answer. I am not so experienced at asm
> but I tried debugging as your advice.
>
> The bootloader checks IFR for any BSP interrupts, finds that MCBSP0
> interrupt is active and jumps to 0xf95d as below
>
> 000:F8D1 6101 BITF IFR,400h
> 0000:F8D3 F930 CC 0f967h,TC
> 0000:F8D5 6101 BITF IFR,40h
> 0000:F8D7 F930 CC 0f971h,TC
> 0000:F8D9 6101 BITF IFR,10h
> 0000:F8DB F930 CC 0f95dh,TC
>
> code at 0xf95d is:
>
> 0000:F95D 7738 STM 0h,38h
> 0000:F95F 7716 STM 39h,AR6
> 0000:F961 7711 STM 21h,AR1
> 0000:F963 7701 STM 10h,IFR
> 0000:F965 F073 B 0f97bh
>
> saves adresses of MCBSP0 registers and jumps to 0xf97b:
>
> 0000:F97B 4881 LDM *AR1,A ->DRR0 is written to A.
> 0000:F97C F110 SUB #10aah,0,A,B ->Subtract 10aa from A, shift by 0 and write result to B
> 0000:F97E F84D BC 0f981h,BEQ -> conditional jump if BEQ(B=0)
> 0000:F980 FC00 RET
>
> at this point it does not jump to 0f981 and continues from next step.
> A is read as 0 and also adress 0x21 at data memory(DRR0) is 0. I
> checked the signal from scope and it seems OK. What can be the reason
> for DSP not reading the data correctly? Thank you.
That's excellent work -- you're on the right track for sure. It appears to me that
McBSP0 simply received the wrong word. You can display the contents of acc A and
find out what actually was received. Is the bit order reversed? Is a bit missing?
The value is shifted by one or more bits? There are many things to check, including
clock polarity, frame sync delay, lsb vs. msb order, etc.
-Jeff
Reply by ●October 10, 20082008-10-10
Hi Jeff,
The problem is solved with your help. After debugging the asm code and being able to see what the dsp receives from the serial port, it was very easy to solve the remaining part. I worked so much on changing timing, delay and polarity for the signals before this debugging. After this debug I found that my polarity was wrong and then dsp started to receive the shifted version of what I sent. With a little delay modification now I am able to boot the dsp. Your messages were really helpful, thank you very much...
The problem is solved with your help. After debugging the asm code and being able to see what the dsp receives from the serial port, it was very easy to solve the remaining part. I worked so much on changing timing, delay and polarity for the signals before this debugging. After this debug I found that my polarity was wrong and then dsp started to receive the shifted version of what I sent. With a little delay modification now I am able to boot the dsp. Your messages were really helpful, thank you very much...
Reply by ●October 10, 20082008-10-10
Erhan-
> The problem is solved with your help. After debugging the asm code and
> being able to see what the dsp receives from the serial port, it was
> very easy to solve the remaining part. I worked so much on changing
> timing, delay and polarity for the signals before this debugging. After
> this debug I found that my polarity was wrong and then dsp started to
> receive the shifted version of what I sent. With a little delay
> modification now I am able to boot the dsp. Your messages were really
> helpful, thank you very much...
Good work Erhan! Glad to hear about the progress. Every now and then, there is a
day when DSP programming is really fun :-)
-Jeff
> The problem is solved with your help. After debugging the asm code and
> being able to see what the dsp receives from the serial port, it was
> very easy to solve the remaining part. I worked so much on changing
> timing, delay and polarity for the signals before this debugging. After
> this debug I found that my polarity was wrong and then dsp started to
> receive the shifted version of what I sent. With a little delay
> modification now I am able to boot the dsp. Your messages were really
> helpful, thank you very much...
Good work Erhan! Glad to hear about the progress. Every now and then, there is a
day when DSP programming is really fun :-)
-Jeff
Reply by ●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?
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?
Reply by ●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').
> 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 ●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?
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 ●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
> 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
