Buddy,
A c6713 is designed to bootload from FLASH memory.
There are some cases:
1. As usually,power on ,we can see the address space
(0x00000000~0x000003ff).It should be filled by the data loaded from
the FLASH. But the first 4 bytes( 0x00000000~0x00000003) are always
filled by 0xFFFFFFFF .
2. In the case 1,if we reset the DSP by the CCS. Then ,the firt 4 bytes
will reload the data from flash correctly.
3. In the case 1,if we reset DSP by giving a reset signal on the RESET
pin of DSP. The first 4 bytes are filled by 0xFFFFFFFF still.
I do not know why?
TMS320C6713 bootload
Started by ●November 24, 2007
Reply by ●November 25, 20072007-11-25
Deng Zhi Bin-
> A c6713 is designed to bootload from FLASH memory.
> There are some cases:
> 1. As usually,power on ,we can see the address space
> (0x00000000~0x000003ff).It should be filled by the data loaded from
> the FLASH. But the first 4 bytes( 0x00000000~0x00000003) are always
> filled by 0xFFFFFFFF .
> 2. In the case 1,if we reset the DSP by the CCS. Then ,the firt 4 bytes
> will reload the data from flash correctly.
> 3. In the case 1,if we reset DSP by giving a reset signal on the RESET
> pin of DSP. The first 4 bytes are filled by 0xFFFFFFFF still.
> I do not know why?
First, what board is this? Without knowing that, it's hard to say... Second, are
you saying that *only* the first 4 bytes are wrong? The remainder of the 1k bytes is
correct?
If only the first 4 bytes are bad, then my guess would be that running CCS introduces
a delay that allows the Flash device to initialize. In your board design, what is
connected to the Flash device Reset line?
-Jeff
> A c6713 is designed to bootload from FLASH memory.
> There are some cases:
> 1. As usually,power on ,we can see the address space
> (0x00000000~0x000003ff).It should be filled by the data loaded from
> the FLASH. But the first 4 bytes( 0x00000000~0x00000003) are always
> filled by 0xFFFFFFFF .
> 2. In the case 1,if we reset the DSP by the CCS. Then ,the firt 4 bytes
> will reload the data from flash correctly.
> 3. In the case 1,if we reset DSP by giving a reset signal on the RESET
> pin of DSP. The first 4 bytes are filled by 0xFFFFFFFF still.
> I do not know why?
First, what board is this? Without knowing that, it's hard to say... Second, are
you saying that *only* the first 4 bytes are wrong? The remainder of the 1k bytes is
correct?
If only the first 4 bytes are bad, then my guess would be that running CCS introduces
a delay that allows the Flash device to initialize. In your board design, what is
connected to the Flash device Reset line?
-Jeff
Reply by ●November 25, 20072007-11-25
Deng Zhi-Bin-
> I want to say ,only the first 4 bytes is not correct.The remainder of the 1k
> bytes are correct. And the FLASH's reset line is pulled up by a resister. You've
> given me a advice,I'll test it later. Thanks a lot.
You might try holding the DSP in reset longer. I assume you have the DSP Reset
asserted at power-on for a period as specified in the data sheet? You might try
extending that period. 1 msec is a safe duration.
Also, normally Flash device Reset is active low -- are you sure your Flash device
doesn't need to have an initial low duration?
-Jeff
PS. Please post to the group, not to me.
> ??2007-11-25??"Jeff Brower" ??????
>
> Deng Zhi Bin-
>
> > A c6713 is designed to bootload from FLASH memory.
> > There are some cases:
> > 1. As usually,power on ,we can see the address space
> > (0x00000000~0x000003ff).It should be filled by the data loaded from
> > the FLASH. But the first 4 bytes( 0x00000000~0x00000003) are always
> > filled by 0xFFFFFFFF .
> > 2. In the case 1,if we reset the DSP by the CCS. Then ,the firt 4 bytes
> > will reload the data from flash correctly.
> > 3. In the case 1,if we reset DSP by giving a reset signal on the RESET
> > pin of DSP. The first 4 bytes are filled by 0xFFFFFFFF still.
> > I do not know why?
>
> First, what board is this? Without knowing that, it's hard to say... Second, are
> you saying that *only* the first 4 bytes are wrong? The remainder of the 1k bytes is
> correct?
>
> If only the first 4 bytes are bad, then my guess would be that running CCS introduces
> a delay that allows the Flash device to initialize. In your board design, what is
> connected to the Flash device Reset line?
>
> -Jeff
>
> I want to say ,only the first 4 bytes is not correct.The remainder of the 1k
> bytes are correct. And the FLASH's reset line is pulled up by a resister. You've
> given me a advice,I'll test it later. Thanks a lot.
You might try holding the DSP in reset longer. I assume you have the DSP Reset
asserted at power-on for a period as specified in the data sheet? You might try
extending that period. 1 msec is a safe duration.
Also, normally Flash device Reset is active low -- are you sure your Flash device
doesn't need to have an initial low duration?
-Jeff
PS. Please post to the group, not to me.
> ??2007-11-25??"Jeff Brower" ??????
>
> Deng Zhi Bin-
>
> > A c6713 is designed to bootload from FLASH memory.
> > There are some cases:
> > 1. As usually,power on ,we can see the address space
> > (0x00000000~0x000003ff).It should be filled by the data loaded from
> > the FLASH. But the first 4 bytes( 0x00000000~0x00000003) are always
> > filled by 0xFFFFFFFF .
> > 2. In the case 1,if we reset the DSP by the CCS. Then ,the firt 4 bytes
> > will reload the data from flash correctly.
> > 3. In the case 1,if we reset DSP by giving a reset signal on the RESET
> > pin of DSP. The first 4 bytes are filled by 0xFFFFFFFF still.
> > I do not know why?
>
> First, what board is this? Without knowing that, it's hard to say... Second, are
> you saying that *only* the first 4 bytes are wrong? The remainder of the 1k bytes is
> correct?
>
> If only the first 4 bytes are bad, then my guess would be that running CCS introduces
> a delay that allows the Flash device to initialize. In your board design, what is
> connected to the Flash device Reset line?
>
> -Jeff
>
Reply by ●November 25, 20072007-11-25
check your flash content
do the same but with a reset instruction in the debugger, the same as the reset but the debugger do not loose controlcheck content of memory with and without cache bypass, it can happen sometimes that you think the content is FF, but it's because of the cache
do the same but with a reset instruction in the debugger, the same as the reset but the debugger do not loose controlcheck content of memory with and without cache bypass, it can happen sometimes that you think the content is FF, but it's because of the cache
Reply by ●November 26, 20072007-11-26
Dear dengzhibin,
A CPU Reset in Code Composer only bootloads from Flash and then halts the
DSP at address 0, while a hardware reset also executes the code.
Maybe your program/bootloader code overwrites the first four bytes during
execution?
Regards,
Adolf Klemenz, D.SignT
At 10:22 23.11.2007 +0000, bigbibby2002 wrote:
>Buddy,
>A c6713 is designed to bootload from FLASH memory.
>There are some cases:
>1. As usually,power on ,we can see the address space
>(0x00000000~0x000003ff).It should be filled by the data loaded from
>the FLASH. But the first 4 bytes( 0x00000000~0x00000003) are always
>filled by 0xFFFFFFFF .
>2. In the case 1,if we reset the DSP by the CCS. Then ,the firt 4 bytes
>will reload the data from flash correctly.
>3. In the case 1,if we reset DSP by giving a reset signal on the RESET
>pin of DSP. The first 4 bytes are filled by 0xFFFFFFFF still.
>I do not know why?
A CPU Reset in Code Composer only bootloads from Flash and then halts the
DSP at address 0, while a hardware reset also executes the code.
Maybe your program/bootloader code overwrites the first four bytes during
execution?
Regards,
Adolf Klemenz, D.SignT
At 10:22 23.11.2007 +0000, bigbibby2002 wrote:
>Buddy,
>A c6713 is designed to bootload from FLASH memory.
>There are some cases:
>1. As usually,power on ,we can see the address space
>(0x00000000~0x000003ff).It should be filled by the data loaded from
>the FLASH. But the first 4 bytes( 0x00000000~0x00000003) are always
>filled by 0xFFFFFFFF .
>2. In the case 1,if we reset the DSP by the CCS. Then ,the firt 4 bytes
>will reload the data from flash correctly.
>3. In the case 1,if we reset DSP by giving a reset signal on the RESET
>pin of DSP. The first 4 bytes are filled by 0xFFFFFFFF still.
>I do not know why?