dragon,
I might wonder about that line of code:
Proto_CPLD_Input_SW1=(io_port_values&0x0400000)==0
According to my understanding, the '=' gets performed before the
'=='
so, this assignment is performed first:
Proto_CPLD_Input_SW1=(io_port_values&0x0400000)
then this comparison:
(io_port_values&0x0400000)==0
May I suggest the following change:
Proto_CPLD_Input_SW1 = ( (io_port_values&0x0400000) == 0 );
then Proto_CPLD_Input_SW1 is set to 'true' or 'false'
I.E. if the bit is '1' then Proto_CPLD_Input_SW1 is set
'false;
otherwise Proto_CPLD_Input_SW1 is set 'true'
And while any value, in a variable, other than '0' will be treated as
'true', I would
suggest being explicit in your assignments
Also,
It takes an extended amount of time to erase a section of flash. (up to 11
seconds on some DSPs.)
So the executed line(s) that created the problem were executed long before this
'if' statement.
R. Williams
---------- Original Message -----------
From: d...@yahoo.com
To: c...
Sent: Thu, 19 Jun 2008 08:15:29 -0400
Subject: [c6x] Re: Undesired flash writing after bootloading
> Hi,
> Thank you for the advices! With your help I have identified the piece of code
that is
> causing the problem. I am still not sure if it is a hardware or software
problem, but it
> is provoked by the software. I have found the piece of code by inserting
endless loops in
> the software and then observing the result. The flash got corrupted after
this line: if
> (Proto_CPLD_Input_SW1==1) Unfortunately I can not understand why this
comparison erases
> the flash. The CCS is not showing me any code, after this command line, when I
switch on
> “view mixed source/asm”. The integer variable
Proto_CPLD_Input_SW1 initializes its
> value by the following commands: io_port_values=*(unsigned volatile int
*)IO_PORT;
> Proto_CPLD_Input_SW1=(io_port_values&0x0400000)==0; The above ones are the
same in any
> DSK example, which is making me confused why my flash is erased. I will be
grateful if
> you give me any ideas?
>
> Thank you in advance
> Drago
>
> Hi,
> > I have successfully implemented a second-level DSP/BIOS bootloader on C6711D
and my application
works well. The problem is that the first sector of the flash is erased
after some time. Only the
first value is random while the rest are FF. This time may vary from days to
months.
> > The DSP relies on the IPU/IPD for its default boot
mode – 8 bit asynchronous flash.
> > I have observed (at the scope) 4 writing operations after the copy of the
first 1k into the
internal memory. These write operations occur 1 micro second after the
copy of the bootloader (the
DSP clock frequency is 50 MHz). Therefore they are surely not as a result from
the bootloader
instructions. The strange part is that these writing operations seems to be at
random space. I have
observed them many times after the reset and transferring the bootloader into
the internal ram.
Therefore I am ordering them with the bigger probability to occur at the top:
> > 4 writing operations at CE0 space - external
RAM
> > 4 writing operations at CE3 space – not used in my board
> > no writing operations – which is correct
> >
> > I did not observed writing operations at CE1 and CE2, but I suppose that the
corrupted flash is
because of writing at CE1.
> > During these write operations the addresses, data
and CE signals are not changing. However they
are not the same after each reset. Most often EA4 is varying and some
others too.
> > Do you have any idea why the DSP performs these 4
writes? I did not find any description of such
a behavior in its documentation! At least give me some suggestions to
clear this problem.
> >
> >Thank you in advance!
> >
> > Dragomir Nikolov
Undesired flash writing after bootloading
Started by ●June 15, 2008
Reply by ●June 20, 20082008-06-20
Reply by ●June 20, 20082008-06-20
Richard-
> I might wonder about that line of code:
>
> Proto_CPLD_Input_SW1=(io_port_values&0x0400000)==0
>
> According to my understanding, the '=' gets performed before the '=='
> so, this assignment is performed first:
> Proto_CPLD_Input_SW1=(io_port_values&0x0400000)
>
> then this comparison:
> (io_port_values&0x0400000)==0
>
> May I suggest the following change:
> Proto_CPLD_Input_SW1 = ( (io_port_values&0x0400000) == 0 );
>
> then Proto_CPLD_Input_SW1 is set to 'true' or 'false'
> I.E. if the bit is '1' then Proto_CPLD_Input_SW1 is set 'false;
> otherwise Proto_CPLD_Input_SW1 is set 'true'
>
> And while any value, in a variable, other than '0' will be
> treated as 'true', I would suggest being explicit in your
> assignments
>
> Also,
>
> It takes an extended amount of time to erase a section of flash. (up to 11 seconds on some DSPs.)
> So the executed line(s) that created the problem were executed long before this 'if' statement.
Flash sector erase time is highly device-dependent, including how much data in the
sector actually needs to be erased. It's conceivable that Dragomir's Flash gets a
sector erased very quick... but it's harder to see how the perfect combination of
commands and command sequence can be emitted by a bit of errant DSP code. Did I say
logic analyzer :-)
-Jeff
> ---------- Original Message -----------
> From: d...@yahoo.com
> To: c...
> Sent: Thu, 19 Jun 2008 08:15:29 -0400
> Subject: [c6x] Re: Undesired flash writing after bootloading
>
> > Hi,
> > Thank you for the advices! With your help I have identified the piece of code that is
> > causing the problem. I am still not sure if it is a hardware or software problem, but it
> > is provoked by the software. I have found the piece of code by inserting endless loops in
> > the software and then observing the result. The flash got corrupted after this line: if
> > (Proto_CPLD_Input_SW1==1) Unfortunately I can not understand why this comparison erases
> > the flash. The CCS is not showing me any code, after this command line, when I switch on
> > “view mixed source/asm”. The integer variable Proto_CPLD_Input_SW1 initializes its
> > value by the following commands: io_port_values=*(unsigned volatile int *)IO_PORT;
> > Proto_CPLD_Input_SW1=(io_port_values&0x0400000)==0; The above ones are the same in any
> > DSK example, which is making me confused why my flash is erased. I will be grateful if
> > you give me any ideas?
> >
> > Thank you in advance
> > Drago
> >
> > Hi,
> > > I have successfully implemented a second-level DSP/BIOS bootloader on C6711D and my application
> works well. The problem is that the first sector of the flash is erased after some time. Only the
> first value is random while the rest are FF. This time may vary from days to months.
> > > The DSP relies on the IPU/IPD for its default boot mode – 8 bit asynchronous flash.
> > > I have observed (at the scope) 4 writing operations after the copy of the first 1k into the
> internal memory. These write operations occur 1 micro second after the copy of the bootloader (the
> DSP clock frequency is 50 MHz). Therefore they are surely not as a result from the bootloader
> instructions. The strange part is that these writing operations seems to be at random space. I have
> observed them many times after the reset and transferring the bootloader into the internal ram.
> Therefore I am ordering them with the bigger probability to occur at the top:
> > > 4 writing operations at CE0 space - external RAM
> > > 4 writing operations at CE3 space – not used in my board
> > > no writing operations – which is correct
> > >
> > > I did not observed writing operations at CE1 and CE2, but I suppose that the corrupted flash is
> because of writing at CE1.
> > > During these write operations the addresses, data and CE signals are not changing. However they
> are not the same after each reset. Most often EA4 is varying and some others too.
> > > Do you have any idea why the DSP performs these 4 writes? I did not find any description of such
> a behavior in its documentation! At least give me some suggestions to clear this problem.
> > >
> > >Thank you in advance!
> > >
> > > Dragomir Nikolov
> I might wonder about that line of code:
>
> Proto_CPLD_Input_SW1=(io_port_values&0x0400000)==0
>
> According to my understanding, the '=' gets performed before the '=='
> so, this assignment is performed first:
> Proto_CPLD_Input_SW1=(io_port_values&0x0400000)
>
> then this comparison:
> (io_port_values&0x0400000)==0
>
> May I suggest the following change:
> Proto_CPLD_Input_SW1 = ( (io_port_values&0x0400000) == 0 );
>
> then Proto_CPLD_Input_SW1 is set to 'true' or 'false'
> I.E. if the bit is '1' then Proto_CPLD_Input_SW1 is set 'false;
> otherwise Proto_CPLD_Input_SW1 is set 'true'
>
> And while any value, in a variable, other than '0' will be
> treated as 'true', I would suggest being explicit in your
> assignments
>
> Also,
>
> It takes an extended amount of time to erase a section of flash. (up to 11 seconds on some DSPs.)
> So the executed line(s) that created the problem were executed long before this 'if' statement.
Flash sector erase time is highly device-dependent, including how much data in the
sector actually needs to be erased. It's conceivable that Dragomir's Flash gets a
sector erased very quick... but it's harder to see how the perfect combination of
commands and command sequence can be emitted by a bit of errant DSP code. Did I say
logic analyzer :-)
-Jeff
> ---------- Original Message -----------
> From: d...@yahoo.com
> To: c...
> Sent: Thu, 19 Jun 2008 08:15:29 -0400
> Subject: [c6x] Re: Undesired flash writing after bootloading
>
> > Hi,
> > Thank you for the advices! With your help I have identified the piece of code that is
> > causing the problem. I am still not sure if it is a hardware or software problem, but it
> > is provoked by the software. I have found the piece of code by inserting endless loops in
> > the software and then observing the result. The flash got corrupted after this line: if
> > (Proto_CPLD_Input_SW1==1) Unfortunately I can not understand why this comparison erases
> > the flash. The CCS is not showing me any code, after this command line, when I switch on
> > “view mixed source/asm”. The integer variable Proto_CPLD_Input_SW1 initializes its
> > value by the following commands: io_port_values=*(unsigned volatile int *)IO_PORT;
> > Proto_CPLD_Input_SW1=(io_port_values&0x0400000)==0; The above ones are the same in any
> > DSK example, which is making me confused why my flash is erased. I will be grateful if
> > you give me any ideas?
> >
> > Thank you in advance
> > Drago
> >
> > Hi,
> > > I have successfully implemented a second-level DSP/BIOS bootloader on C6711D and my application
> works well. The problem is that the first sector of the flash is erased after some time. Only the
> first value is random while the rest are FF. This time may vary from days to months.
> > > The DSP relies on the IPU/IPD for its default boot mode – 8 bit asynchronous flash.
> > > I have observed (at the scope) 4 writing operations after the copy of the first 1k into the
> internal memory. These write operations occur 1 micro second after the copy of the bootloader (the
> DSP clock frequency is 50 MHz). Therefore they are surely not as a result from the bootloader
> instructions. The strange part is that these writing operations seems to be at random space. I have
> observed them many times after the reset and transferring the bootloader into the internal ram.
> Therefore I am ordering them with the bigger probability to occur at the top:
> > > 4 writing operations at CE0 space - external RAM
> > > 4 writing operations at CE3 space – not used in my board
> > > no writing operations – which is correct
> > >
> > > I did not observed writing operations at CE1 and CE2, but I suppose that the corrupted flash is
> because of writing at CE1.
> > > During these write operations the addresses, data and CE signals are not changing. However they
> are not the same after each reset. Most often EA4 is varying and some others too.
> > > Do you have any idea why the DSP performs these 4 writes? I did not find any description of such
> a behavior in its documentation! At least give me some suggestions to clear this problem.
> > >
> > >Thank you in advance!
> > >
> > > Dragomir Nikolov
Reply by ●June 20, 20082008-06-20
Dragomir-
> Thank you for the advices! With your help I have identified the
> piece of code that is causing the problem. I am still not sure if it is
> a hardware or software problem, but it is provoked by the software. I
> have found the piece of code by inserting endless loops in the software
> and then observing the result.
That's good work. Debug may not be as fun as design, but certainly it's just as
challenging!
> The flash got corrupted after this line:
> if (Proto_CPLD_Input_SW1==1)
> Unfortunately I can not understand why this comparison erases
> the flash.
As Richard mentions, it's probably not just one line of code that's causing a bad
effect. You might have found a loose string, then you have to pull on it to unravel
all that's going on. There might be a combination of things that eventually cause
the Flash to become corrupted.
You should put a logic analyzer on the Flash strobe/control signals and try to "see"
exactly what the Flash sees. Obviously if it never gets a true, accurate write
sequence then it must be something else that is causing it to lose data. But if it
does, then you would know that your DSP code and/or onboard firmware is somehow
emitting that sequence.
> The CCS is not showing me any code, after this command
> line, when I switch on “view mixed source/asm”.
> The integer variable Proto_CPLD_Input_SW1 initializes its
> value by the following commands:
> io_port_values=*(unsigned volatile int *)IO_PORT;
> Proto_CPLD_Input_SW1=(io_port_values&0x0400000)==0;
> The above ones are the same in any DSK example, which is
> making me confused why my flash is erased.
Does your board design contain the same CPLD and switches as the DSK? My guess is
not. For example, in which EMIF space is the IO_PORT address on the DSK board? Does
that correspond to the Flash addr space on your board?
In general, using "DSK specific code" on your board may cause issues if there are
even slight differences.
-Jeff
> > I have successfully implemented a second-level DSP/BIOS bootloader on C6711D and my application works well. The problem is that the first sector of the flash is erased after some time. Only the first value is random while the rest are FF. This time may vary from days to months.
> > The DSP relies on the IPU/IPD for its default boot mode – 8 bit asynchronous flash.
> > I have observed (at the scope) 4 writing operations after the copy of the first 1k into the internal memory. These write operations occur 1 micro second after the copy of the bootloader (the DSP clock frequency is 50 MHz). Therefore they are surely not as a result from the bootloader instructions. The strange part is that these writing operations seems to be at random space. I have observed them many times after the reset and transferring the bootloader into the internal ram. Therefore I am ordering them with the bigger probability to occur at the top:
> > 4 writing operations at CE0 space - external RAM
> > 4 writing operations at CE3 space – not used in my board
> > no writing operations – which is correct
> >
> > I did not observed writing operations at CE1 and CE2, but I suppose that the corrupted flash is because of writing at CE1.
> > During these write operations the addresses, data and CE signals are not changing. However they are not the same after each reset. Most often EA4 is varying and some others too.
> > Do you have any idea why the DSP performs these 4 writes? I did not find any description of such a behavior in its documentation! At least give me some suggestions to clear this problem.
> >
> >Thank you in advance!
> Thank you for the advices! With your help I have identified the
> piece of code that is causing the problem. I am still not sure if it is
> a hardware or software problem, but it is provoked by the software. I
> have found the piece of code by inserting endless loops in the software
> and then observing the result.
That's good work. Debug may not be as fun as design, but certainly it's just as
challenging!
> The flash got corrupted after this line:
> if (Proto_CPLD_Input_SW1==1)
> Unfortunately I can not understand why this comparison erases
> the flash.
As Richard mentions, it's probably not just one line of code that's causing a bad
effect. You might have found a loose string, then you have to pull on it to unravel
all that's going on. There might be a combination of things that eventually cause
the Flash to become corrupted.
You should put a logic analyzer on the Flash strobe/control signals and try to "see"
exactly what the Flash sees. Obviously if it never gets a true, accurate write
sequence then it must be something else that is causing it to lose data. But if it
does, then you would know that your DSP code and/or onboard firmware is somehow
emitting that sequence.
> The CCS is not showing me any code, after this command
> line, when I switch on “view mixed source/asm”.
> The integer variable Proto_CPLD_Input_SW1 initializes its
> value by the following commands:
> io_port_values=*(unsigned volatile int *)IO_PORT;
> Proto_CPLD_Input_SW1=(io_port_values&0x0400000)==0;
> The above ones are the same in any DSK example, which is
> making me confused why my flash is erased.
Does your board design contain the same CPLD and switches as the DSK? My guess is
not. For example, in which EMIF space is the IO_PORT address on the DSK board? Does
that correspond to the Flash addr space on your board?
In general, using "DSK specific code" on your board may cause issues if there are
even slight differences.
-Jeff
> > I have successfully implemented a second-level DSP/BIOS bootloader on C6711D and my application works well. The problem is that the first sector of the flash is erased after some time. Only the first value is random while the rest are FF. This time may vary from days to months.
> > The DSP relies on the IPU/IPD for its default boot mode – 8 bit asynchronous flash.
> > I have observed (at the scope) 4 writing operations after the copy of the first 1k into the internal memory. These write operations occur 1 micro second after the copy of the bootloader (the DSP clock frequency is 50 MHz). Therefore they are surely not as a result from the bootloader instructions. The strange part is that these writing operations seems to be at random space. I have observed them many times after the reset and transferring the bootloader into the internal ram. Therefore I am ordering them with the bigger probability to occur at the top:
> > 4 writing operations at CE0 space - external RAM
> > 4 writing operations at CE3 space – not used in my board
> > no writing operations – which is correct
> >
> > I did not observed writing operations at CE1 and CE2, but I suppose that the corrupted flash is because of writing at CE1.
> > During these write operations the addresses, data and CE signals are not changing. However they are not the same after each reset. Most often EA4 is varying and some others too.
> > Do you have any idea why the DSP performs these 4 writes? I did not find any description of such a behavior in its documentation! At least give me some suggestions to clear this problem.
> >
> >Thank you in advance!
