Sign in
Search msp430
Subscribe to msp430
Ads
Discussion Groups
Discussion Groups | MSP430 | flash woes revisited
The purpose of this group is to foster exchange of information on the Texas Instruments MSP430 family of microcontrollers and related tools. Everyone welcome, all levels of familiarity/expertise.
flash woes revisited - "e.tury" - Sep 9 13:15:51 2008
Now that I can count by 2, I'm back to debugging the original flash
write problem: skipping a write for no (apparent) reason.
I've padded my table with consecutive addresses as shown below.
The flash gets erased before every attempt, and the 0xFFFFs always show
up in the debug window when I check.
Running the loop twice doesn't fill in the blanks. Another assembled
board shows exactly the same bad writes.
I'm going nuts.
Any suggestions for more experiments would be appreciated.
I am using IAR Workbench 4.0;
code:
#pragma location = 0x4000
const uint16 Measurements[4096];
const uint16 Test_Calibration_Data[] = {
3453,0,
.........
.........
1198,700,
1194,701,
1191,702,
1189,703,
1188,704,//test
1187,704,//test
1186,704,
1185,704,//test
1184,704,//test
1183,704,//test
1182,705,//test
1181,705,
1180,706,//test
1179,706,//test
1178,706,//test
1177,706,
1176,706,//test
1175,706,//test
1174,707,
1173,707,//test
1172,707,//test
1171,708,
1167,709,
.....
.....
};
00491E FFFF FFFF
004922 FFFF FFFF
004926 02C4
004928 02C3
00492A 02C3
00492C 02C3
00492E FFFF 02C2 //bad write @ 1175
004932 02C2 //706
004934 02C2
004936 02C2
004938 FFFF 02C1 //bad write @ 1180
00493C 02C1
00493E 02C0
004940 FFFF 02C0 //bad write @1184
004944 FFFF 02C0 //bad write @ 1186
004948 FFFF 02BF
00494C FFFF 02BE
004950 FFFF FFFF
004954 02BD FFFF
004958 FFFF FFFF
00495C 02BC FFFF
004960 FFFF FFFF
004964 FFFF FFFF
004968 FFFF 02BA
00496C FFFF FFFF
004970 FFFF FFFF
for (i=0; i<2002; i+=2)
{
if(Measurements[i] == 0xFFFF)
{
Flash_Write_Word((int16*) &(Measurements[Test_Calibration_Data[i]]),
Test_Calibration_Data[i+1]);
}
void Flash_Write_Word(int16 *data_pointer, int16 word)
{
FCTL3 = FWKEY; // Clear LOCK
FCTL1 = FWKEY + WRT; // Enable WRITE
*data_pointer = word; // program Flash word
FCTL1 = FWKEY; // Clear WRITE
FCTL3 = FWKEY + LOCK; // Set LOCK
}
Edd
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: flash woes revisited - old_cow_yellow - Sep 9 17:16:01 2008
The address of a "word" must be an even number.
--- In m...@yahoogroups.com, "e.tury" wrote:
> Now that I can count by 2, I'm back to debugging the original flash
> write problem: skipping a write for no (apparent) reason.
>
> I've padded my table with consecutive addresses as shown below.
>
> The flash gets erased before every attempt, and the 0xFFFFs always show
> up in the debug window when I check.
>
> Running the loop twice doesn't fill in the blanks. Another assembled
> board shows exactly the same bad writes.
>
> I'm going nuts.
>
> Any suggestions for more experiments would be appreciated.
>
> I am using IAR Workbench 4.0;
>
> code:
>
> #pragma location = 0x4000
>
> const uint16 Measurements[4096];
>
> const uint16 Test_Calibration_Data[] = {
> 3453,0,
> .........
> .........
>
> 1198,700,
> 1194,701,
> 1191,702,
> 1189,703,
> 1188,704,//test
> 1187,704,//test
> 1186,704,
> 1185,704,//test
> 1184,704,//test
> 1183,704,//test
> 1182,705,//test
> 1181,705,
> 1180,706,//test
> 1179,706,//test
> 1178,706,//test
> 1177,706,
> 1176,706,//test
> 1175,706,//test
> 1174,707,
> 1173,707,//test
> 1172,707,//test
> 1171,708,
> 1167,709,
> .....
> .....
> };
>
> 00491E FFFF FFFF
> 004922 FFFF FFFF
> 004926 02C4
> 004928 02C3
> 00492A 02C3
> 00492C 02C3
> 00492E FFFF 02C2 //bad write @ 1175
> 004932 02C2 //706
> 004934 02C2
> 004936 02C2
> 004938 FFFF 02C1 //bad write @ 1180
> 00493C 02C1
> 00493E 02C0
> 004940 FFFF 02C0 //bad write @1184
> 004944 FFFF 02C0 //bad write @ 1186
> 004948 FFFF 02BF
> 00494C FFFF 02BE
> 004950 FFFF FFFF
> 004954 02BD FFFF
> 004958 FFFF FFFF
> 00495C 02BC FFFF
> 004960 FFFF FFFF
> 004964 FFFF FFFF
> 004968 FFFF 02BA
> 00496C FFFF FFFF
> 004970 FFFF FFFF
> for (i=0; i<2002; i+=2)
> {
>
> if(Measurements[i] == 0xFFFF)
> {
>
> Flash_Write_Word((int16*) &(Measurements[Test_Calibration_Data[i]]),
> Test_Calibration_Data[i+1]);
> }
>
> void Flash_Write_Word(int16 *data_pointer, int16 word)
> {
> FCTL3 = FWKEY; // Clear LOCK
> FCTL1 = FWKEY + WRT; // Enable WRITE
>
> *data_pointer = word; // program Flash word
>
> FCTL1 = FWKEY; // Clear WRITE
> FCTL3 = FWKEY + LOCK; // Set LOCK
>
> }
> Edd
>
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
--- In m...@yahoogroups.com, "e.tury"
> Now that I can count by 2, I'm back to debugging the original flash
> write problem: skipping a write for no (apparent) reason.
>
> I've padded my table with consecutive addresses as shown below.
>
> The flash gets erased before every attempt, and the 0xFFFFs always show
> up in the debug window when I check.
>
> Running the loop twice doesn't fill in the blanks. Another assembled
> board shows exactly the same bad writes.
>
> I'm going nuts.
>
> Any suggestions for more experiments would be appreciated.
>
> I am using IAR Workbench 4.0;
>
> code:
>
> #pragma location = 0x4000
>
> const uint16 Measurements[4096];
>
> const uint16 Test_Calibration_Data[] = {
> 3453,0,
> .........
> .........
>
> 1198,700,
> 1194,701,
> 1191,702,
> 1189,703,
> 1188,704,//test
> 1187,704,//test
> 1186,704,
> 1185,704,//test
> 1184,704,//test
> 1183,704,//test
> 1182,705,//test
> 1181,705,
> 1180,706,//test
> 1179,706,//test
> 1178,706,//test
> 1177,706,
> 1176,706,//test
> 1175,706,//test
> 1174,707,
> 1173,707,//test
> 1172,707,//test
> 1171,708,
> 1167,709,
> .....
> .....
> };
>
> 00491E FFFF FFFF
> 004922 FFFF FFFF
> 004926 02C4
> 004928 02C3
> 00492A 02C3
> 00492C 02C3
> 00492E FFFF 02C2 //bad write @ 1175
> 004932 02C2 //706
> 004934 02C2
> 004936 02C2
> 004938 FFFF 02C1 //bad write @ 1180
> 00493C 02C1
> 00493E 02C0
> 004940 FFFF 02C0 //bad write @1184
> 004944 FFFF 02C0 //bad write @ 1186
> 004948 FFFF 02BF
> 00494C FFFF 02BE
> 004950 FFFF FFFF
> 004954 02BD FFFF
> 004958 FFFF FFFF
> 00495C 02BC FFFF
> 004960 FFFF FFFF
> 004964 FFFF FFFF
> 004968 FFFF 02BA
> 00496C FFFF FFFF
> 004970 FFFF FFFF
> for (i=0; i<2002; i+=2)
> {
>
> if(Measurements[i] == 0xFFFF)
> {
>
> Flash_Write_Word((int16*) &(Measurements[Test_Calibration_Data[i]]),
> Test_Calibration_Data[i+1]);
> }
>
> void Flash_Write_Word(int16 *data_pointer, int16 word)
> {
> FCTL3 = FWKEY; // Clear LOCK
> FCTL1 = FWKEY + WRT; // Enable WRITE
>
> *data_pointer = word; // program Flash word
>
> FCTL1 = FWKEY; // Clear WRITE
> FCTL3 = FWKEY + LOCK; // Set LOCK
>
> }
> Edd
>
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: flash woes revisited - "e.tury" - Sep 10 7:03:55 2008
Greetings O_C_Y,
Yes it does. However, in this case the "address" is actually an
offset into an array of words that are aligned on even number
addresses.
I'm convinced the problem has to do with flash timing, cpu memory
accesses, or power issues. I'm seeking some TI input.
I was able to write the table correctly by doing an immediate check
of the "just written" cell, and if it was still OxFFFF, rewrite it.
That worked every time.
Edd
--- In m...@yahoogroups.com, "old_cow_yellow"
wrote:
>
> The address of a "word" must be an even number.
>
> --- In m...@yahoogroups.com, "e.tury" wrote:
> >
> >
> > Now that I can count by 2, I'm back to debugging the original
flash
> > write problem: skipping a write for no (apparent) reason.
> >
> > I've padded my table with consecutive addresses as shown below.
> >
> > The flash gets erased before every attempt, and the 0xFFFFs
always show
> > up in the debug window when I check.
> >
> > Running the loop twice doesn't fill in the blanks. Another
assembled
> > board shows exactly the same bad writes.
> >
> > I'm going nuts.
> >
> > Any suggestions for more experiments would be appreciated.
> >
> > I am using IAR Workbench 4.0;
> >
> > code:
> >
> > #pragma location = 0x4000
> >
> > const uint16 Measurements[4096];
> >
> > const uint16 Test_Calibration_Data[] = {
> > 3453,0,
> > .........
> > .........
> >
> > 1198,700,
> > 1194,701,
> > 1191,702,
> > 1189,703,
> > 1188,704,//test
> > 1187,704,//test
> > 1186,704,
> > 1185,704,//test
> > 1184,704,//test
> > 1183,704,//test
> > 1182,705,//test
> > 1181,705,
> > 1180,706,//test
> > 1179,706,//test
> > 1178,706,//test
> > 1177,706,
> > 1176,706,//test
> > 1175,706,//test
> > 1174,707,
> > 1173,707,//test
> > 1172,707,//test
> > 1171,708,
> > 1167,709,
> > .....
> > .....
> >
> >
> > };
> >
> > 00491E FFFF FFFF
> > 004922 FFFF FFFF
> > 004926 02C4
> > 004928 02C3
> > 00492A 02C3
> > 00492C 02C3
> > 00492E FFFF 02C2 //bad write @ 1175
> > 004932 02C2 //706
> > 004934 02C2
> > 004936 02C2
> > 004938 FFFF 02C1 //bad write @ 1180
> > 00493C 02C1
> > 00493E 02C0
> > 004940 FFFF 02C0 //bad write @1184
> > 004944 FFFF 02C0 //bad write @ 1186
> > 004948 FFFF 02BF
> > 00494C FFFF 02BE
> > 004950 FFFF FFFF
> > 004954 02BD FFFF
> > 004958 FFFF FFFF
> > 00495C 02BC FFFF
> > 004960 FFFF FFFF
> > 004964 FFFF FFFF
> > 004968 FFFF 02BA
> > 00496C FFFF FFFF
> > 004970 FFFF FFFF
> >
> >
> > for (i=0; i<2002; i+=2)
> > {
> >
> > if(Measurements[i] == 0xFFFF)
> > {
> >
> > Flash_Write_Word((int16*) &(Measurements[Test_Calibration_Data
[i]]),
> > Test_Calibration_Data[i+1]);
> >
> >
> > }
> >
> > void Flash_Write_Word(int16 *data_pointer, int16 word)
> > {
> >
> >
> > FCTL3 = FWKEY; // Clear LOCK
> > FCTL1 = FWKEY + WRT; // Enable WRITE
> >
> > *data_pointer = word; // program Flash word
> >
> > FCTL1 = FWKEY; // Clear WRITE
> > FCTL3 = FWKEY + LOCK; // Set LOCK
> >
> > }
> >
> >
> > Edd
>
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Yes it does. However, in this case the "address" is actually an
offset into an array of words that are aligned on even number
addresses.
I'm convinced the problem has to do with flash timing, cpu memory
accesses, or power issues. I'm seeking some TI input.
I was able to write the table correctly by doing an immediate check
of the "just written" cell, and if it was still OxFFFF, rewrite it.
That worked every time.
Edd
--- In m...@yahoogroups.com, "old_cow_yellow"
wrote:
>
> The address of a "word" must be an even number.
>
> --- In m...@yahoogroups.com, "e.tury"
> >
> >
> > Now that I can count by 2, I'm back to debugging the original
flash
> > write problem: skipping a write for no (apparent) reason.
> >
> > I've padded my table with consecutive addresses as shown below.
> >
> > The flash gets erased before every attempt, and the 0xFFFFs
always show
> > up in the debug window when I check.
> >
> > Running the loop twice doesn't fill in the blanks. Another
assembled
> > board shows exactly the same bad writes.
> >
> > I'm going nuts.
> >
> > Any suggestions for more experiments would be appreciated.
> >
> > I am using IAR Workbench 4.0;
> >
> > code:
> >
> > #pragma location = 0x4000
> >
> > const uint16 Measurements[4096];
> >
> > const uint16 Test_Calibration_Data[] = {
> > 3453,0,
> > .........
> > .........
> >
> > 1198,700,
> > 1194,701,
> > 1191,702,
> > 1189,703,
> > 1188,704,//test
> > 1187,704,//test
> > 1186,704,
> > 1185,704,//test
> > 1184,704,//test
> > 1183,704,//test
> > 1182,705,//test
> > 1181,705,
> > 1180,706,//test
> > 1179,706,//test
> > 1178,706,//test
> > 1177,706,
> > 1176,706,//test
> > 1175,706,//test
> > 1174,707,
> > 1173,707,//test
> > 1172,707,//test
> > 1171,708,
> > 1167,709,
> > .....
> > .....
> >
> >
> > };
> >
> > 00491E FFFF FFFF
> > 004922 FFFF FFFF
> > 004926 02C4
> > 004928 02C3
> > 00492A 02C3
> > 00492C 02C3
> > 00492E FFFF 02C2 //bad write @ 1175
> > 004932 02C2 //706
> > 004934 02C2
> > 004936 02C2
> > 004938 FFFF 02C1 //bad write @ 1180
> > 00493C 02C1
> > 00493E 02C0
> > 004940 FFFF 02C0 //bad write @1184
> > 004944 FFFF 02C0 //bad write @ 1186
> > 004948 FFFF 02BF
> > 00494C FFFF 02BE
> > 004950 FFFF FFFF
> > 004954 02BD FFFF
> > 004958 FFFF FFFF
> > 00495C 02BC FFFF
> > 004960 FFFF FFFF
> > 004964 FFFF FFFF
> > 004968 FFFF 02BA
> > 00496C FFFF FFFF
> > 004970 FFFF FFFF
> >
> >
> > for (i=0; i<2002; i+=2)
> > {
> >
> > if(Measurements[i] == 0xFFFF)
> > {
> >
> > Flash_Write_Word((int16*) &(Measurements[Test_Calibration_Data
[i]]),
> > Test_Calibration_Data[i+1]);
> >
> >
> > }
> >
> > void Flash_Write_Word(int16 *data_pointer, int16 word)
> > {
> >
> >
> > FCTL3 = FWKEY; // Clear LOCK
> > FCTL1 = FWKEY + WRT; // Enable WRITE
> >
> > *data_pointer = word; // program Flash word
> >
> > FCTL1 = FWKEY; // Clear WRITE
> > FCTL3 = FWKEY + LOCK; // Set LOCK
> >
> > }
> >
> >
> > Edd
>
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: flash woes revisited - old_cow_yellow - Sep 10 10:13:19 2008
I am not sure what you mean.
[address] = [base]+[offset]
[address] has to be even.
[base] is known to be even.
Are you saying that in this case
[offset] can be either even or odd?
That seems odd - I mean strange ;)
--- In m...@yahoogroups.com, "e.tury" wrote:
>
> Greetings O_C_Y,
>
> Yes it does. However, in this case the "address" is actually an
> offset into an array of words that are aligned on even number
> addresses.
>
> I'm convinced the problem has to do with flash timing, cpu memory
> accesses, or power issues. I'm seeking some TI input.
>
> I was able to write the table correctly by doing an immediate check
> of the "just written" cell, and if it was still OxFFFF, rewrite it.
> That worked every time.
>
> Edd
> --- In m...@yahoogroups.com, "old_cow_yellow"
> wrote:
> >
> > The address of a "word" must be an even number.
> >
> > --- In m...@yahoogroups.com, "e.tury" wrote:
> > >
> > >
> > > Now that I can count by 2, I'm back to debugging the original
> flash
> > > write problem: skipping a write for no (apparent) reason.
> > >
> > > I've padded my table with consecutive addresses as shown below.
> > >
> > > The flash gets erased before every attempt, and the 0xFFFFs
> always show
> > > up in the debug window when I check.
> > >
> > > Running the loop twice doesn't fill in the blanks. Another
> assembled
> > > board shows exactly the same bad writes.
> > >
> > > I'm going nuts.
> > >
> > > Any suggestions for more experiments would be appreciated.
> > >
> > > I am using IAR Workbench 4.0;
> > >
> > > code:
> > >
> > > #pragma location = 0x4000
> > >
> > > const uint16 Measurements[4096];
> > >
> > > const uint16 Test_Calibration_Data[] = {
> > > 3453,0,
> > > .........
> > > .........
> > >
> > > 1198,700,
> > > 1194,701,
> > > 1191,702,
> > > 1189,703,
> > > 1188,704,//test
> > > 1187,704,//test
> > > 1186,704,
> > > 1185,704,//test
> > > 1184,704,//test
> > > 1183,704,//test
> > > 1182,705,//test
> > > 1181,705,
> > > 1180,706,//test
> > > 1179,706,//test
> > > 1178,706,//test
> > > 1177,706,
> > > 1176,706,//test
> > > 1175,706,//test
> > > 1174,707,
> > > 1173,707,//test
> > > 1172,707,//test
> > > 1171,708,
> > > 1167,709,
> > > .....
> > > .....
> > >
> > >
> > > };
> > >
> > > 00491E FFFF FFFF
> > > 004922 FFFF FFFF
> > > 004926 02C4
> > > 004928 02C3
> > > 00492A 02C3
> > > 00492C 02C3
> > > 00492E FFFF 02C2 //bad write @ 1175
> > > 004932 02C2 //706
> > > 004934 02C2
> > > 004936 02C2
> > > 004938 FFFF 02C1 //bad write @ 1180
> > > 00493C 02C1
> > > 00493E 02C0
> > > 004940 FFFF 02C0 //bad write @1184
> > > 004944 FFFF 02C0 //bad write @ 1186
> > > 004948 FFFF 02BF
> > > 00494C FFFF 02BE
> > > 004950 FFFF FFFF
> > > 004954 02BD FFFF
> > > 004958 FFFF FFFF
> > > 00495C 02BC FFFF
> > > 004960 FFFF FFFF
> > > 004964 FFFF FFFF
> > > 004968 FFFF 02BA
> > > 00496C FFFF FFFF
> > > 004970 FFFF FFFF
> > >
> > >
> > > for (i=0; i<2002; i+=2)
> > > {
> > >
> > > if(Measurements[i] == 0xFFFF)
> > > {
> > >
> > > Flash_Write_Word((int16*) &(Measurements[Test_Calibration_Data
> [i]]),
> > > Test_Calibration_Data[i+1]);
> > >
> > >
> > > }
> > >
> > > void Flash_Write_Word(int16 *data_pointer, int16 word)
> > > {
> > >
> > >
> > > FCTL3 = FWKEY; // Clear LOCK
> > > FCTL1 = FWKEY + WRT; // Enable WRITE
> > >
> > > *data_pointer = word; // program Flash word
> > >
> > > FCTL1 = FWKEY; // Clear WRITE
> > > FCTL3 = FWKEY + LOCK; // Set LOCK
> > >
> > > }
> > >
> > >
> > > Edd
> > >
>
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
[address] = [base]+[offset]
[address] has to be even.
[base] is known to be even.
Are you saying that in this case
[offset] can be either even or odd?
That seems odd - I mean strange ;)
--- In m...@yahoogroups.com, "e.tury"
>
> Greetings O_C_Y,
>
> Yes it does. However, in this case the "address" is actually an
> offset into an array of words that are aligned on even number
> addresses.
>
> I'm convinced the problem has to do with flash timing, cpu memory
> accesses, or power issues. I'm seeking some TI input.
>
> I was able to write the table correctly by doing an immediate check
> of the "just written" cell, and if it was still OxFFFF, rewrite it.
> That worked every time.
>
> Edd
> --- In m...@yahoogroups.com, "old_cow_yellow"
> wrote:
> >
> > The address of a "word" must be an even number.
> >
> > --- In m...@yahoogroups.com, "e.tury"
> > >
> > >
> > > Now that I can count by 2, I'm back to debugging the original
> flash
> > > write problem: skipping a write for no (apparent) reason.
> > >
> > > I've padded my table with consecutive addresses as shown below.
> > >
> > > The flash gets erased before every attempt, and the 0xFFFFs
> always show
> > > up in the debug window when I check.
> > >
> > > Running the loop twice doesn't fill in the blanks. Another
> assembled
> > > board shows exactly the same bad writes.
> > >
> > > I'm going nuts.
> > >
> > > Any suggestions for more experiments would be appreciated.
> > >
> > > I am using IAR Workbench 4.0;
> > >
> > > code:
> > >
> > > #pragma location = 0x4000
> > >
> > > const uint16 Measurements[4096];
> > >
> > > const uint16 Test_Calibration_Data[] = {
> > > 3453,0,
> > > .........
> > > .........
> > >
> > > 1198,700,
> > > 1194,701,
> > > 1191,702,
> > > 1189,703,
> > > 1188,704,//test
> > > 1187,704,//test
> > > 1186,704,
> > > 1185,704,//test
> > > 1184,704,//test
> > > 1183,704,//test
> > > 1182,705,//test
> > > 1181,705,
> > > 1180,706,//test
> > > 1179,706,//test
> > > 1178,706,//test
> > > 1177,706,
> > > 1176,706,//test
> > > 1175,706,//test
> > > 1174,707,
> > > 1173,707,//test
> > > 1172,707,//test
> > > 1171,708,
> > > 1167,709,
> > > .....
> > > .....
> > >
> > >
> > > };
> > >
> > > 00491E FFFF FFFF
> > > 004922 FFFF FFFF
> > > 004926 02C4
> > > 004928 02C3
> > > 00492A 02C3
> > > 00492C 02C3
> > > 00492E FFFF 02C2 //bad write @ 1175
> > > 004932 02C2 //706
> > > 004934 02C2
> > > 004936 02C2
> > > 004938 FFFF 02C1 //bad write @ 1180
> > > 00493C 02C1
> > > 00493E 02C0
> > > 004940 FFFF 02C0 //bad write @1184
> > > 004944 FFFF 02C0 //bad write @ 1186
> > > 004948 FFFF 02BF
> > > 00494C FFFF 02BE
> > > 004950 FFFF FFFF
> > > 004954 02BD FFFF
> > > 004958 FFFF FFFF
> > > 00495C 02BC FFFF
> > > 004960 FFFF FFFF
> > > 004964 FFFF FFFF
> > > 004968 FFFF 02BA
> > > 00496C FFFF FFFF
> > > 004970 FFFF FFFF
> > >
> > >
> > > for (i=0; i<2002; i+=2)
> > > {
> > >
> > > if(Measurements[i] == 0xFFFF)
> > > {
> > >
> > > Flash_Write_Word((int16*) &(Measurements[Test_Calibration_Data
> [i]]),
> > > Test_Calibration_Data[i+1]);
> > >
> > >
> > > }
> > >
> > > void Flash_Write_Word(int16 *data_pointer, int16 word)
> > > {
> > >
> > >
> > > FCTL3 = FWKEY; // Clear LOCK
> > > FCTL1 = FWKEY + WRT; // Enable WRITE
> > >
> > > *data_pointer = word; // program Flash word
> > >
> > > FCTL1 = FWKEY; // Clear WRITE
> > > FCTL3 = FWKEY + LOCK; // Set LOCK
> > >
> > > }
> > >
> > >
> > > Edd
> > >
>
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: flash woes revisited - "e.tury" - Sep 10 11:59:28 2008
My array of ints has origin at 0x4000. It is 4096 ints long.
If I write to 'array[odd number]' I am still writing to an even
address since every array[n] is at an even address no matter the
value of n.
--- In m...@yahoogroups.com, "old_cow_yellow"
wrote:
>
> I am not sure what you mean.
>
> [address] = [base]+[offset]
>
> [address] has to be even.
> [base] is known to be even.
>
> Are you saying that in this case
> [offset] can be either even or odd?
>
> That seems odd - I mean strange ;)
>
> --- In m...@yahoogroups.com, "e.tury" wrote:
> >
> > Greetings O_C_Y,
> >
> > Yes it does. However, in this case the "address" is actually an
> > offset into an array of words that are aligned on even number
> > addresses.
> >
> > I'm convinced the problem has to do with flash timing, cpu memory
> > accesses, or power issues. I'm seeking some TI input.
> >
> > I was able to write the table correctly by doing an immediate
check
> > of the "just written" cell, and if it was still OxFFFF, rewrite
it.
> > That worked every time.
> >
> > Edd
> >
> >
> > --- In m...@yahoogroups.com, "old_cow_yellow"
> > wrote:
> > >
> > > The address of a "word" must be an even number.
> > >
> > > --- In m...@yahoogroups.com, "e.tury" wrote:
> > > >
> > > >
> > > > Now that I can count by 2, I'm back to debugging the
original
> > flash
> > > > write problem: skipping a write for no (apparent) reason.
> > > >
> > > > I've padded my table with consecutive addresses as shown
below.
> > > >
> > > > The flash gets erased before every attempt, and the 0xFFFFs
> > always show
> > > > up in the debug window when I check.
> > > >
> > > > Running the loop twice doesn't fill in the blanks. Another
> > assembled
> > > > board shows exactly the same bad writes.
> > > >
> > > > I'm going nuts.
> > > >
> > > > Any suggestions for more experiments would be appreciated.
> > > >
> > > > I am using IAR Workbench 4.0;
> > > >
> > > > code:
> > > >
> > > > #pragma location = 0x4000
> > > >
> > > > const uint16 Measurements[4096];
> > > >
> > > > const uint16 Test_Calibration_Data[] = {
> > > > 3453,0,
> > > > .........
> > > > .........
> > > >
> > > > 1198,700,
> > > > 1194,701,
> > > > 1191,702,
> > > > 1189,703,
> > > > 1188,704,//test
> > > > 1187,704,//test
> > > > 1186,704,
> > > > 1185,704,//test
> > > > 1184,704,//test
> > > > 1183,704,//test
> > > > 1182,705,//test
> > > > 1181,705,
> > > > 1180,706,//test
> > > > 1179,706,//test
> > > > 1178,706,//test
> > > > 1177,706,
> > > > 1176,706,//test
> > > > 1175,706,//test
> > > > 1174,707,
> > > > 1173,707,//test
> > > > 1172,707,//test
> > > > 1171,708,
> > > > 1167,709,
> > > > .....
> > > > .....
> > > >
> > > >
> > > > };
> > > >
> > > > 00491E FFFF FFFF
> > > > 004922 FFFF FFFF
> > > > 004926 02C4
> > > > 004928 02C3
> > > > 00492A 02C3
> > > > 00492C 02C3
> > > > 00492E FFFF 02C2 //bad write @ 1175
> > > > 004932 02C2 //706
> > > > 004934 02C2
> > > > 004936 02C2
> > > > 004938 FFFF 02C1 //bad write @ 1180
> > > > 00493C 02C1
> > > > 00493E 02C0
> > > > 004940 FFFF 02C0 //bad write @1184
> > > > 004944 FFFF 02C0 //bad write @ 1186
> > > > 004948 FFFF 02BF
> > > > 00494C FFFF 02BE
> > > > 004950 FFFF FFFF
> > > > 004954 02BD FFFF
> > > > 004958 FFFF FFFF
> > > > 00495C 02BC FFFF
> > > > 004960 FFFF FFFF
> > > > 004964 FFFF FFFF
> > > > 004968 FFFF 02BA
> > > > 00496C FFFF FFFF
> > > > 004970 FFFF FFFF
> > > >
> > > >
> > > > for (i=0; i<2002; i+=2)
> > > > {
> > > >
> > > > if(Measurements[i] == 0xFFFF)
> > > > {
> > > >
> > > > Flash_Write_Word((int16*) &(Measurements
[Test_Calibration_Data
> > [i]]),
> > > > Test_Calibration_Data[i+1]);
> > > >
> > > >
> > > > }
> > > >
> > > > void Flash_Write_Word(int16 *data_pointer, int16 word)
> > > > {
> > > >
> > > >
> > > > FCTL3 = FWKEY; // Clear LOCK
> > > > FCTL1 = FWKEY + WRT; // Enable WRITE
> > > >
> > > > *data_pointer = word; // program Flash word
> > > >
> > > > FCTL1 = FWKEY; // Clear WRITE
> > > > FCTL3 = FWKEY + LOCK; // Set LOCK
> > > >
> > > > }
> > > >
> > > >
> > > > Edd
> > > >
> > >
>
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
If I write to 'array[odd number]' I am still writing to an even
address since every array[n] is at an even address no matter the
value of n.
--- In m...@yahoogroups.com, "old_cow_yellow"
wrote:
>
> I am not sure what you mean.
>
> [address] = [base]+[offset]
>
> [address] has to be even.
> [base] is known to be even.
>
> Are you saying that in this case
> [offset] can be either even or odd?
>
> That seems odd - I mean strange ;)
>
> --- In m...@yahoogroups.com, "e.tury"
> >
> > Greetings O_C_Y,
> >
> > Yes it does. However, in this case the "address" is actually an
> > offset into an array of words that are aligned on even number
> > addresses.
> >
> > I'm convinced the problem has to do with flash timing, cpu memory
> > accesses, or power issues. I'm seeking some TI input.
> >
> > I was able to write the table correctly by doing an immediate
check
> > of the "just written" cell, and if it was still OxFFFF, rewrite
it.
> > That worked every time.
> >
> > Edd
> >
> >
> > --- In m...@yahoogroups.com, "old_cow_yellow"
> > wrote:
> > >
> > > The address of a "word" must be an even number.
> > >
> > > --- In m...@yahoogroups.com, "e.tury"
> > > >
> > > >
> > > > Now that I can count by 2, I'm back to debugging the
original
> > flash
> > > > write problem: skipping a write for no (apparent) reason.
> > > >
> > > > I've padded my table with consecutive addresses as shown
below.
> > > >
> > > > The flash gets erased before every attempt, and the 0xFFFFs
> > always show
> > > > up in the debug window when I check.
> > > >
> > > > Running the loop twice doesn't fill in the blanks. Another
> > assembled
> > > > board shows exactly the same bad writes.
> > > >
> > > > I'm going nuts.
> > > >
> > > > Any suggestions for more experiments would be appreciated.
> > > >
> > > > I am using IAR Workbench 4.0;
> > > >
> > > > code:
> > > >
> > > > #pragma location = 0x4000
> > > >
> > > > const uint16 Measurements[4096];
> > > >
> > > > const uint16 Test_Calibration_Data[] = {
> > > > 3453,0,
> > > > .........
> > > > .........
> > > >
> > > > 1198,700,
> > > > 1194,701,
> > > > 1191,702,
> > > > 1189,703,
> > > > 1188,704,//test
> > > > 1187,704,//test
> > > > 1186,704,
> > > > 1185,704,//test
> > > > 1184,704,//test
> > > > 1183,704,//test
> > > > 1182,705,//test
> > > > 1181,705,
> > > > 1180,706,//test
> > > > 1179,706,//test
> > > > 1178,706,//test
> > > > 1177,706,
> > > > 1176,706,//test
> > > > 1175,706,//test
> > > > 1174,707,
> > > > 1173,707,//test
> > > > 1172,707,//test
> > > > 1171,708,
> > > > 1167,709,
> > > > .....
> > > > .....
> > > >
> > > >
> > > > };
> > > >
> > > > 00491E FFFF FFFF
> > > > 004922 FFFF FFFF
> > > > 004926 02C4
> > > > 004928 02C3
> > > > 00492A 02C3
> > > > 00492C 02C3
> > > > 00492E FFFF 02C2 //bad write @ 1175
> > > > 004932 02C2 //706
> > > > 004934 02C2
> > > > 004936 02C2
> > > > 004938 FFFF 02C1 //bad write @ 1180
> > > > 00493C 02C1
> > > > 00493E 02C0
> > > > 004940 FFFF 02C0 //bad write @1184
> > > > 004944 FFFF 02C0 //bad write @ 1186
> > > > 004948 FFFF 02BF
> > > > 00494C FFFF 02BE
> > > > 004950 FFFF FFFF
> > > > 004954 02BD FFFF
> > > > 004958 FFFF FFFF
> > > > 00495C 02BC FFFF
> > > > 004960 FFFF FFFF
> > > > 004964 FFFF FFFF
> > > > 004968 FFFF 02BA
> > > > 00496C FFFF FFFF
> > > > 004970 FFFF FFFF
> > > >
> > > >
> > > > for (i=0; i<2002; i+=2)
> > > > {
> > > >
> > > > if(Measurements[i] == 0xFFFF)
> > > > {
> > > >
> > > > Flash_Write_Word((int16*) &(Measurements
[Test_Calibration_Data
> > [i]]),
> > > > Test_Calibration_Data[i+1]);
> > > >
> > > >
> > > > }
> > > >
> > > > void Flash_Write_Word(int16 *data_pointer, int16 word)
> > > > {
> > > >
> > > >
> > > > FCTL3 = FWKEY; // Clear LOCK
> > > > FCTL1 = FWKEY + WRT; // Enable WRITE
> > > >
> > > > *data_pointer = word; // program Flash word
> > > >
> > > > FCTL1 = FWKEY; // Clear WRITE
> > > > FCTL3 = FWKEY + LOCK; // Set LOCK
> > > >
> > > > }
> > > >
> > > >
> > > > Edd
> > > >
> > >
>
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: flash woes revisited - old_cow_yellow - Sep 10 13:24:32 2008
So, [offset]=2*[index]
Thus offset is always even, even if [index] is odd.
(; Pardon my English ;)
I think we are both barking up the wrong trees.
How about change:
if(Measurements[i] == 0xFFFF)
...
into:
if(Measurements[Test_Calibration_Data[i]] == 0xFFFF)
...
Any bird up there?
--- In m...@yahoogroups.com, "e.tury" wrote:
> Now that I can count by 2, I'm back to debugging the original flash
> write problem: skipping a write for no (apparent) reason.
>
> I've padded my table with consecutive addresses as shown below.
>
> The flash gets erased before every attempt, and the 0xFFFFs always show
> up in the debug window when I check.
>
> Running the loop twice doesn't fill in the blanks. Another assembled
> board shows exactly the same bad writes.
>
> I'm going nuts.
>
> Any suggestions for more experiments would be appreciated.
>
> I am using IAR Workbench 4.0;
>
> code:
>
> #pragma location = 0x4000
>
> const uint16 Measurements[4096];
>
> const uint16 Test_Calibration_Data[] = {
> 3453,0,
> .........
> .........
>
> 1198,700,
> 1194,701,
> 1191,702,
> 1189,703,
> 1188,704,//test
> 1187,704,//test
> 1186,704,
> 1185,704,//test
> 1184,704,//test
> 1183,704,//test
> 1182,705,//test
> 1181,705,
> 1180,706,//test
> 1179,706,//test
> 1178,706,//test
> 1177,706,
> 1176,706,//test
> 1175,706,//test
> 1174,707,
> 1173,707,//test
> 1172,707,//test
> 1171,708,
> 1167,709,
> .....
> .....
> };
>
> 00491E FFFF FFFF
> 004922 FFFF FFFF
> 004926 02C4
> 004928 02C3
> 00492A 02C3
> 00492C 02C3
> 00492E FFFF 02C2 //bad write @ 1175
> 004932 02C2 //706
> 004934 02C2
> 004936 02C2
> 004938 FFFF 02C1 //bad write @ 1180
> 00493C 02C1
> 00493E 02C0
> 004940 FFFF 02C0 //bad write @1184
> 004944 FFFF 02C0 //bad write @ 1186
> 004948 FFFF 02BF
> 00494C FFFF 02BE
> 004950 FFFF FFFF
> 004954 02BD FFFF
> 004958 FFFF FFFF
> 00495C 02BC FFFF
> 004960 FFFF FFFF
> 004964 FFFF FFFF
> 004968 FFFF 02BA
> 00496C FFFF FFFF
> 004970 FFFF FFFF
> for (i=0; i<2002; i+=2)
> {
>
> if(Measurements[i] == 0xFFFF)
> {
>
> Flash_Write_Word((int16*) &(Measurements[Test_Calibration_Data[i]]),
> Test_Calibration_Data[i+1]);
> }
>
> void Flash_Write_Word(int16 *data_pointer, int16 word)
> {
> FCTL3 = FWKEY; // Clear LOCK
> FCTL1 = FWKEY + WRT; // Enable WRITE
>
> *data_pointer = word; // program Flash word
>
> FCTL1 = FWKEY; // Clear WRITE
> FCTL3 = FWKEY + LOCK; // Set LOCK
>
> }
> Edd
>
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Thus offset is always even, even if [index] is odd.
(; Pardon my English ;)
I think we are both barking up the wrong trees.
How about change:
if(Measurements[i] == 0xFFFF)
...
into:
if(Measurements[Test_Calibration_Data[i]] == 0xFFFF)
...
Any bird up there?
--- In m...@yahoogroups.com, "e.tury"
> Now that I can count by 2, I'm back to debugging the original flash
> write problem: skipping a write for no (apparent) reason.
>
> I've padded my table with consecutive addresses as shown below.
>
> The flash gets erased before every attempt, and the 0xFFFFs always show
> up in the debug window when I check.
>
> Running the loop twice doesn't fill in the blanks. Another assembled
> board shows exactly the same bad writes.
>
> I'm going nuts.
>
> Any suggestions for more experiments would be appreciated.
>
> I am using IAR Workbench 4.0;
>
> code:
>
> #pragma location = 0x4000
>
> const uint16 Measurements[4096];
>
> const uint16 Test_Calibration_Data[] = {
> 3453,0,
> .........
> .........
>
> 1198,700,
> 1194,701,
> 1191,702,
> 1189,703,
> 1188,704,//test
> 1187,704,//test
> 1186,704,
> 1185,704,//test
> 1184,704,//test
> 1183,704,//test
> 1182,705,//test
> 1181,705,
> 1180,706,//test
> 1179,706,//test
> 1178,706,//test
> 1177,706,
> 1176,706,//test
> 1175,706,//test
> 1174,707,
> 1173,707,//test
> 1172,707,//test
> 1171,708,
> 1167,709,
> .....
> .....
> };
>
> 00491E FFFF FFFF
> 004922 FFFF FFFF
> 004926 02C4
> 004928 02C3
> 00492A 02C3
> 00492C 02C3
> 00492E FFFF 02C2 //bad write @ 1175
> 004932 02C2 //706
> 004934 02C2
> 004936 02C2
> 004938 FFFF 02C1 //bad write @ 1180
> 00493C 02C1
> 00493E 02C0
> 004940 FFFF 02C0 //bad write @1184
> 004944 FFFF 02C0 //bad write @ 1186
> 004948 FFFF 02BF
> 00494C FFFF 02BE
> 004950 FFFF FFFF
> 004954 02BD FFFF
> 004958 FFFF FFFF
> 00495C 02BC FFFF
> 004960 FFFF FFFF
> 004964 FFFF FFFF
> 004968 FFFF 02BA
> 00496C FFFF FFFF
> 004970 FFFF FFFF
> for (i=0; i<2002; i+=2)
> {
>
> if(Measurements[i] == 0xFFFF)
> {
>
> Flash_Write_Word((int16*) &(Measurements[Test_Calibration_Data[i]]),
> Test_Calibration_Data[i+1]);
> }
>
> void Flash_Write_Word(int16 *data_pointer, int16 word)
> {
> FCTL3 = FWKEY; // Clear LOCK
> FCTL1 = FWKEY + WRT; // Enable WRITE
>
> *data_pointer = word; // program Flash word
>
> FCTL1 = FWKEY; // Clear WRITE
> FCTL3 = FWKEY + LOCK; // Set LOCK
>
> }
> Edd
>
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: flash woes revisited - "e.tury" - Sep 10 15:19:18 2008
I'll have to think that through. (May take a while!)
I am in touch with a TI guy who emailed me some flash write code
using indirection (pointers). The big difference I see is that he
turns on the flash programmer clock, etc. THEN does a whole array
write, then turns flash writing off. Whereas my writes are internal
to the loop, so the flash stuff gets cycled on and off for each
write, instead of once per bunch o' writes.
I appreciate your input.
Edd
--- In m...@yahoogroups.com, "old_cow_yellow"
wrote:
>
> So, [offset]=2*[index]
> Thus offset is always even, even if [index] is odd.
> (; Pardon my English ;)
>
> I think we are both barking up the wrong trees.
>
> How about change:
>
> if(Measurements[i] == 0xFFFF)
> ...
>
> into:
>
> if(Measurements[Test_Calibration_Data[i]] == 0xFFFF)
> ...
>
> Any bird up there?
>
> --- In m...@yahoogroups.com, "e.tury" wrote:
> >
> >
> > Now that I can count by 2, I'm back to debugging the original
flash
> > write problem: skipping a write for no (apparent) reason.
> >
> > I've padded my table with consecutive addresses as shown below.
> >
> > The flash gets erased before every attempt, and the 0xFFFFs
always show
> > up in the debug window when I check.
> >
> > Running the loop twice doesn't fill in the blanks. Another
assembled
> > board shows exactly the same bad writes.
> >
> > I'm going nuts.
> >
> > Any suggestions for more experiments would be appreciated.
> >
> > I am using IAR Workbench 4.0;
> >
> > code:
> >
> > #pragma location = 0x4000
> >
> > const uint16 Measurements[4096];
> >
> > const uint16 Test_Calibration_Data[] = {
> > 3453,0,
> > .........
> > .........
> >
> > 1198,700,
> > 1194,701,
> > 1191,702,
> > 1189,703,
> > 1188,704,//test
> > 1187,704,//test
> > 1186,704,
> > 1185,704,//test
> > 1184,704,//test
> > 1183,704,//test
> > 1182,705,//test
> > 1181,705,
> > 1180,706,//test
> > 1179,706,//test
> > 1178,706,//test
> > 1177,706,
> > 1176,706,//test
> > 1175,706,//test
> > 1174,707,
> > 1173,707,//test
> > 1172,707,//test
> > 1171,708,
> > 1167,709,
> > .....
> > .....
> >
> >
> > };
> >
> > 00491E FFFF FFFF
> > 004922 FFFF FFFF
> > 004926 02C4
> > 004928 02C3
> > 00492A 02C3
> > 00492C 02C3
> > 00492E FFFF 02C2 //bad write @ 1175
> > 004932 02C2 //706
> > 004934 02C2
> > 004936 02C2
> > 004938 FFFF 02C1 //bad write @ 1180
> > 00493C 02C1
> > 00493E 02C0
> > 004940 FFFF 02C0 //bad write @1184
> > 004944 FFFF 02C0 //bad write @ 1186
> > 004948 FFFF 02BF
> > 00494C FFFF 02BE
> > 004950 FFFF FFFF
> > 004954 02BD FFFF
> > 004958 FFFF FFFF
> > 00495C 02BC FFFF
> > 004960 FFFF FFFF
> > 004964 FFFF FFFF
> > 004968 FFFF 02BA
> > 00496C FFFF FFFF
> > 004970 FFFF FFFF
> >
> >
> > for (i=0; i<2002; i+=2)
> > {
> >
> > if(Measurements[i] == 0xFFFF)
> > {
> >
> > Flash_Write_Word((int16*) &(Measurements[Test_Calibration_Data
[i]]),
> > Test_Calibration_Data[i+1]);
> >
> >
> > }
> >
> > void Flash_Write_Word(int16 *data_pointer, int16 word)
> > {
> >
> >
> > FCTL3 = FWKEY; // Clear LOCK
> > FCTL1 = FWKEY + WRT; // Enable WRITE
> >
> > *data_pointer = word; // program Flash word
> >
> > FCTL1 = FWKEY; // Clear WRITE
> > FCTL3 = FWKEY + LOCK; // Set LOCK
> >
> > }
> >
> >
> > Edd
>
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
I am in touch with a TI guy who emailed me some flash write code
using indirection (pointers). The big difference I see is that he
turns on the flash programmer clock, etc. THEN does a whole array
write, then turns flash writing off. Whereas my writes are internal
to the loop, so the flash stuff gets cycled on and off for each
write, instead of once per bunch o' writes.
I appreciate your input.
Edd
--- In m...@yahoogroups.com, "old_cow_yellow"
wrote:
>
> So, [offset]=2*[index]
> Thus offset is always even, even if [index] is odd.
> (; Pardon my English ;)
>
> I think we are both barking up the wrong trees.
>
> How about change:
>
> if(Measurements[i] == 0xFFFF)
> ...
>
> into:
>
> if(Measurements[Test_Calibration_Data[i]] == 0xFFFF)
> ...
>
> Any bird up there?
>
> --- In m...@yahoogroups.com, "e.tury"
> >
> >
> > Now that I can count by 2, I'm back to debugging the original
flash
> > write problem: skipping a write for no (apparent) reason.
> >
> > I've padded my table with consecutive addresses as shown below.
> >
> > The flash gets erased before every attempt, and the 0xFFFFs
always show
> > up in the debug window when I check.
> >
> > Running the loop twice doesn't fill in the blanks. Another
assembled
> > board shows exactly the same bad writes.
> >
> > I'm going nuts.
> >
> > Any suggestions for more experiments would be appreciated.
> >
> > I am using IAR Workbench 4.0;
> >
> > code:
> >
> > #pragma location = 0x4000
> >
> > const uint16 Measurements[4096];
> >
> > const uint16 Test_Calibration_Data[] = {
> > 3453,0,
> > .........
> > .........
> >
> > 1198,700,
> > 1194,701,
> > 1191,702,
> > 1189,703,
> > 1188,704,//test
> > 1187,704,//test
> > 1186,704,
> > 1185,704,//test
> > 1184,704,//test
> > 1183,704,//test
> > 1182,705,//test
> > 1181,705,
> > 1180,706,//test
> > 1179,706,//test
> > 1178,706,//test
> > 1177,706,
> > 1176,706,//test
> > 1175,706,//test
> > 1174,707,
> > 1173,707,//test
> > 1172,707,//test
> > 1171,708,
> > 1167,709,
> > .....
> > .....
> >
> >
> > };
> >
> > 00491E FFFF FFFF
> > 004922 FFFF FFFF
> > 004926 02C4
> > 004928 02C3
> > 00492A 02C3
> > 00492C 02C3
> > 00492E FFFF 02C2 //bad write @ 1175
> > 004932 02C2 //706
> > 004934 02C2
> > 004936 02C2
> > 004938 FFFF 02C1 //bad write @ 1180
> > 00493C 02C1
> > 00493E 02C0
> > 004940 FFFF 02C0 //bad write @1184
> > 004944 FFFF 02C0 //bad write @ 1186
> > 004948 FFFF 02BF
> > 00494C FFFF 02BE
> > 004950 FFFF FFFF
> > 004954 02BD FFFF
> > 004958 FFFF FFFF
> > 00495C 02BC FFFF
> > 004960 FFFF FFFF
> > 004964 FFFF FFFF
> > 004968 FFFF 02BA
> > 00496C FFFF FFFF
> > 004970 FFFF FFFF
> >
> >
> > for (i=0; i<2002; i+=2)
> > {
> >
> > if(Measurements[i] == 0xFFFF)
> > {
> >
> > Flash_Write_Word((int16*) &(Measurements[Test_Calibration_Data
[i]]),
> > Test_Calibration_Data[i+1]);
> >
> >
> > }
> >
> > void Flash_Write_Word(int16 *data_pointer, int16 word)
> > {
> >
> >
> > FCTL3 = FWKEY; // Clear LOCK
> > FCTL1 = FWKEY + WRT; // Enable WRITE
> >
> > *data_pointer = word; // program Flash word
> >
> > FCTL1 = FWKEY; // Clear WRITE
> > FCTL3 = FWKEY + LOCK; // Set LOCK
> >
> > }
> >
> >
> > Edd
>
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: flash woes revisited - old_cow_yellow - Sep 10 16:18:14 2008
Writing one word at time is not efficient and might wear out the Flash
if you keep doing that.
But that was NOT the cause of the unexpected result you got.
You are checking if the word Measurements[i] is 0xFFFF. If it is, then
you proceed to write at a different location, namely:
Measurements[Test_Calibration_Data[i]]
Only if that location happens to be 0xFFFF, then it is okay.
Read you code again, and THINK!
--- In m...@yahoogroups.com, "e.tury" wrote:
>
> I'll have to think that through. (May take a while!)
>
> I am in touch with a TI guy who emailed me some flash write code
> using indirection (pointers). The big difference I see is that he
> turns on the flash programmer clock, etc. THEN does a whole array
> write, then turns flash writing off. Whereas my writes are internal
> to the loop, so the flash stuff gets cycled on and off for each
> write, instead of once per bunch o' writes.
>
> I appreciate your input.
>
> Edd
>
> --- In m...@yahoogroups.com, "old_cow_yellow"
> wrote:
> >
> > So, [offset]=2*[index]
> > Thus offset is always even, even if [index] is odd.
> > (; Pardon my English ;)
> >
> > I think we are both barking up the wrong trees.
> >
> > How about change:
> >
> > if(Measurements[i] == 0xFFFF)
> > ...
> >
> > into:
> >
> > if(Measurements[Test_Calibration_Data[i]] == 0xFFFF)
> > ...
> >
> > Any bird up there?
> >
> > --- In m...@yahoogroups.com, "e.tury" wrote:
> > >
> > >
> > > Now that I can count by 2, I'm back to debugging the original
> flash
> > > write problem: skipping a write for no (apparent) reason.
> > >
> > > I've padded my table with consecutive addresses as shown below.
> > >
> > > The flash gets erased before every attempt, and the 0xFFFFs
> always show
> > > up in the debug window when I check.
> > >
> > > Running the loop twice doesn't fill in the blanks. Another
> assembled
> > > board shows exactly the same bad writes.
> > >
> > > I'm going nuts.
> > >
> > > Any suggestions for more experiments would be appreciated.
> > >
> > > I am using IAR Workbench 4.0;
> > >
> > > code:
> > >
> > > #pragma location = 0x4000
> > >
> > > const uint16 Measurements[4096];
> > >
> > > const uint16 Test_Calibration_Data[] = {
> > > 3453,0,
> > > .........
> > > .........
> > >
> > > 1198,700,
> > > 1194,701,
> > > 1191,702,
> > > 1189,703,
> > > 1188,704,//test
> > > 1187,704,//test
> > > 1186,704,
> > > 1185,704,//test
> > > 1184,704,//test
> > > 1183,704,//test
> > > 1182,705,//test
> > > 1181,705,
> > > 1180,706,//test
> > > 1179,706,//test
> > > 1178,706,//test
> > > 1177,706,
> > > 1176,706,//test
> > > 1175,706,//test
> > > 1174,707,
> > > 1173,707,//test
> > > 1172,707,//test
> > > 1171,708,
> > > 1167,709,
> > > .....
> > > .....
> > >
> > >
> > > };
> > >
> > > 00491E FFFF FFFF
> > > 004922 FFFF FFFF
> > > 004926 02C4
> > > 004928 02C3
> > > 00492A 02C3
> > > 00492C 02C3
> > > 00492E FFFF 02C2 //bad write @ 1175
> > > 004932 02C2 //706
> > > 004934 02C2
> > > 004936 02C2
> > > 004938 FFFF 02C1 //bad write @ 1180
> > > 00493C 02C1
> > > 00493E 02C0
> > > 004940 FFFF 02C0 //bad write @1184
> > > 004944 FFFF 02C0 //bad write @ 1186
> > > 004948 FFFF 02BF
> > > 00494C FFFF 02BE
> > > 004950 FFFF FFFF
> > > 004954 02BD FFFF
> > > 004958 FFFF FFFF
> > > 00495C 02BC FFFF
> > > 004960 FFFF FFFF
> > > 004964 FFFF FFFF
> > > 004968 FFFF 02BA
> > > 00496C FFFF FFFF
> > > 004970 FFFF FFFF
> > >
> > >
> > > for (i=0; i<2002; i+=2)
> > > {
> > >
> > > if(Measurements[i] == 0xFFFF)
> > > {
> > >
> > > Flash_Write_Word((int16*) &(Measurements[Test_Calibration_Data
> [i]]),
> > > Test_Calibration_Data[i+1]);
> > >
> > >
> > > }
> > >
> > > void Flash_Write_Word(int16 *data_pointer, int16 word)
> > > {
> > >
> > >
> > > FCTL3 = FWKEY; // Clear LOCK
> > > FCTL1 = FWKEY + WRT; // Enable WRITE
> > >
> > > *data_pointer = word; // program Flash word
> > >
> > > FCTL1 = FWKEY; // Clear WRITE
> > > FCTL3 = FWKEY + LOCK; // Set LOCK
> > >
> > > }
> > >
> > >
> > > Edd
> > >
>
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
if you keep doing that.
But that was NOT the cause of the unexpected result you got.
You are checking if the word Measurements[i] is 0xFFFF. If it is, then
you proceed to write at a different location, namely:
Measurements[Test_Calibration_Data[i]]
Only if that location happens to be 0xFFFF, then it is okay.
Read you code again, and THINK!
--- In m...@yahoogroups.com, "e.tury"
>
> I'll have to think that through. (May take a while!)
>
> I am in touch with a TI guy who emailed me some flash write code
> using indirection (pointers). The big difference I see is that he
> turns on the flash programmer clock, etc. THEN does a whole array
> write, then turns flash writing off. Whereas my writes are internal
> to the loop, so the flash stuff gets cycled on and off for each
> write, instead of once per bunch o' writes.
>
> I appreciate your input.
>
> Edd
>
> --- In m...@yahoogroups.com, "old_cow_yellow"
> wrote:
> >
> > So, [offset]=2*[index]
> > Thus offset is always even, even if [index] is odd.
> > (; Pardon my English ;)
> >
> > I think we are both barking up the wrong trees.
> >
> > How about change:
> >
> > if(Measurements[i] == 0xFFFF)
> > ...
> >
> > into:
> >
> > if(Measurements[Test_Calibration_Data[i]] == 0xFFFF)
> > ...
> >
> > Any bird up there?
> >
> > --- In m...@yahoogroups.com, "e.tury"
> > >
> > >
> > > Now that I can count by 2, I'm back to debugging the original
> flash
> > > write problem: skipping a write for no (apparent) reason.
> > >
> > > I've padded my table with consecutive addresses as shown below.
> > >
> > > The flash gets erased before every attempt, and the 0xFFFFs
> always show
> > > up in the debug window when I check.
> > >
> > > Running the loop twice doesn't fill in the blanks. Another
> assembled
> > > board shows exactly the same bad writes.
> > >
> > > I'm going nuts.
> > >
> > > Any suggestions for more experiments would be appreciated.
> > >
> > > I am using IAR Workbench 4.0;
> > >
> > > code:
> > >
> > > #pragma location = 0x4000
> > >
> > > const uint16 Measurements[4096];
> > >
> > > const uint16 Test_Calibration_Data[] = {
> > > 3453,0,
> > > .........
> > > .........
> > >
> > > 1198,700,
> > > 1194,701,
> > > 1191,702,
> > > 1189,703,
> > > 1188,704,//test
> > > 1187,704,//test
> > > 1186,704,
> > > 1185,704,//test
> > > 1184,704,//test
> > > 1183,704,//test
> > > 1182,705,//test
> > > 1181,705,
> > > 1180,706,//test
> > > 1179,706,//test
> > > 1178,706,//test
> > > 1177,706,
> > > 1176,706,//test
> > > 1175,706,//test
> > > 1174,707,
> > > 1173,707,//test
> > > 1172,707,//test
> > > 1171,708,
> > > 1167,709,
> > > .....
> > > .....
> > >
> > >
> > > };
> > >
> > > 00491E FFFF FFFF
> > > 004922 FFFF FFFF
> > > 004926 02C4
> > > 004928 02C3
> > > 00492A 02C3
> > > 00492C 02C3
> > > 00492E FFFF 02C2 //bad write @ 1175
> > > 004932 02C2 //706
> > > 004934 02C2
> > > 004936 02C2
> > > 004938 FFFF 02C1 //bad write @ 1180
> > > 00493C 02C1
> > > 00493E 02C0
> > > 004940 FFFF 02C0 //bad write @1184
> > > 004944 FFFF 02C0 //bad write @ 1186
> > > 004948 FFFF 02BF
> > > 00494C FFFF 02BE
> > > 004950 FFFF FFFF
> > > 004954 02BD FFFF
> > > 004958 FFFF FFFF
> > > 00495C 02BC FFFF
> > > 004960 FFFF FFFF
> > > 004964 FFFF FFFF
> > > 004968 FFFF 02BA
> > > 00496C FFFF FFFF
> > > 004970 FFFF FFFF
> > >
> > >
> > > for (i=0; i<2002; i+=2)
> > > {
> > >
> > > if(Measurements[i] == 0xFFFF)
> > > {
> > >
> > > Flash_Write_Word((int16*) &(Measurements[Test_Calibration_Data
> [i]]),
> > > Test_Calibration_Data[i+1]);
> > >
> > >
> > > }
> > >
> > > void Flash_Write_Word(int16 *data_pointer, int16 word)
> > > {
> > >
> > >
> > > FCTL3 = FWKEY; // Clear LOCK
> > > FCTL1 = FWKEY + WRT; // Enable WRITE
> > >
> > > *data_pointer = word; // program Flash word
> > >
> > > FCTL1 = FWKEY; // Clear WRITE
> > > FCTL3 = FWKEY + LOCK; // Set LOCK
> > >
> > > }
> > >
> > >
> > > Edd
> > >
>
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: flash woes revisited - "e.tury" - Sep 10 16:32:36 2008
I see your point. If that was a problem, however, I would expect to
see corrupt writes rather than no writes. The test for 0xFFFF
shouldn't be necessary since the entire portion of flash is always
erased just prior to the table write. But I like your idea.
This flash table write should only occur once in the product's life.
Unfortunately it isn't my code. I just happen to have to support it
and correct the bugs when found.
--- In m...@yahoogroups.com, "old_cow_yellow"
wrote:
>
> Writing one word at time is not efficient and might wear out the
Flash
> if you keep doing that.
>
> But that was NOT the cause of the unexpected result you got.
>
> You are checking if the word Measurements[i] is 0xFFFF. If it is,
then
> you proceed to write at a different location, namely:
> Measurements[Test_Calibration_Data[i]]
> Only if that location happens to be 0xFFFF, then it is okay.
>
> Read you code again, and THINK!
>
> --- In m...@yahoogroups.com, "e.tury" wrote:
> >
> > I'll have to think that through. (May take a while!)
> >
> > I am in touch with a TI guy who emailed me some flash write code
> > using indirection (pointers). The big difference I see is that he
> > turns on the flash programmer clock, etc. THEN does a whole array
> > write, then turns flash writing off. Whereas my writes are
internal
> > to the loop, so the flash stuff gets cycled on and off for each
> > write, instead of once per bunch o' writes.
> >
> > I appreciate your input.
> >
> > Edd
> >
> > --- In m...@yahoogroups.com, "old_cow_yellow"
> > wrote:
> > >
> > > So, [offset]=2*[index]
> > > Thus offset is always even, even if [index] is odd.
> > > (; Pardon my English ;)
> > >
> > > I think we are both barking up the wrong trees.
> > >
> > > How about change:
> > >
> > > if(Measurements[i] == 0xFFFF)
> > > ...
> > >
> > > into:
> > >
> > > if(Measurements[Test_Calibration_Data[i]] == 0xFFFF)
> > > ...
> > >
> > > Any bird up there?
> > >
> > > --- In m...@yahoogroups.com, "e.tury" wrote:
> > > >
> > > >
> > > > Now that I can count by 2, I'm back to debugging the
original
> > flash
> > > > write problem: skipping a write for no (apparent) reason.
> > > >
> > > > I've padded my table with consecutive addresses as shown
below.
> > > >
> > > > The flash gets erased before every attempt, and the 0xFFFFs
> > always show
> > > > up in the debug window when I check.
> > > >
> > > > Running the loop twice doesn't fill in the blanks. Another
> > assembled
> > > > board shows exactly the same bad writes.
> > > >
> > > > I'm going nuts.
> > > >
> > > > Any suggestions for more experiments would be appreciated.
> > > >
> > > > I am using IAR Workbench 4.0;
> > > >
> > > > code:
> > > >
> > > > #pragma location = 0x4000
> > > >
> > > > const uint16 Measurements[4096];
> > > >
> > > > const uint16 Test_Calibration_Data[] = {
> > > > 3453,0,
> > > > .........
> > > > .........
> > > >
> > > > 1198,700,
> > > > 1194,701,
> > > > 1191,702,
> > > > 1189,703,
> > > > 1188,704,//test
> > > > 1187,704,//test
> > > > 1186,704,
> > > > 1185,704,//test
> > > > 1184,704,//test
> > > > 1183,704,//test
> > > > 1182,705,//test
> > > > 1181,705,
> > > > 1180,706,//test
> > > > 1179,706,//test
> > > > 1178,706,//test
> > > > 1177,706,
> > > > 1176,706,//test
> > > > 1175,706,//test
> > > > 1174,707,
> > > > 1173,707,//test
> > > > 1172,707,//test
> > > > 1171,708,
> > > > 1167,709,
> > > > .....
> > > > .....
> > > >
> > > >
> > > > };
> > > >
> > > > 00491E FFFF FFFF
> > > > 004922 FFFF FFFF
> > > > 004926 02C4
> > > > 004928 02C3
> > > > 00492A 02C3
> > > > 00492C 02C3
> > > > 00492E FFFF 02C2 //bad write @ 1175
> > > > 004932 02C2 //706
> > > > 004934 02C2
> > > > 004936 02C2
> > > > 004938 FFFF 02C1 //bad write @ 1180
> > > > 00493C 02C1
> > > > 00493E 02C0
> > > > 004940 FFFF 02C0 //bad write @1184
> > > > 004944 FFFF 02C0 //bad write @ 1186
> > > > 004948 FFFF 02BF
> > > > 00494C FFFF 02BE
> > > > 004950 FFFF FFFF
> > > > 004954 02BD FFFF
> > > > 004958 FFFF FFFF
> > > > 00495C 02BC FFFF
> > > > 004960 FFFF FFFF
> > > > 004964 FFFF FFFF
> > > > 004968 FFFF 02BA
> > > > 00496C FFFF FFFF
> > > > 004970 FFFF FFFF
> > > >
> > > >
> > > > for (i=0; i<2002; i+=2)
> > > > {
> > > >
> > > > if(Measurements[i] == 0xFFFF)
> > > > {
> > > >
> > > > Flash_Write_Word((int16*) &(Measurements
[Test_Calibration_Data
> > [i]]),
> > > > Test_Calibration_Data[i+1]);
> > > >
> > > >
> > > > }
> > > >
> > > > void Flash_Write_Word(int16 *data_pointer, int16 word)
> > > > {
> > > >
> > > >
> > > > FCTL3 = FWKEY; // Clear LOCK
> > > > FCTL1 = FWKEY + WRT; // Enable WRITE
> > > >
> > > > *data_pointer = word; // program Flash word
> > > >
> > > > FCTL1 = FWKEY; // Clear WRITE
> > > > FCTL3 = FWKEY + LOCK; // Set LOCK
> > > >
> > > > }
> > > >
> > > >
> > > > Edd
> > > >
> > >
>
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
see corrupt writes rather than no writes. The test for 0xFFFF
shouldn't be necessary since the entire portion of flash is always
erased just prior to the table write. But I like your idea.
This flash table write should only occur once in the product's life.
Unfortunately it isn't my code. I just happen to have to support it
and correct the bugs when found.
--- In m...@yahoogroups.com, "old_cow_yellow"
wrote:
>
> Writing one word at time is not efficient and might wear out the
Flash
> if you keep doing that.
>
> But that was NOT the cause of the unexpected result you got.
>
> You are checking if the word Measurements[i] is 0xFFFF. If it is,
then
> you proceed to write at a different location, namely:
> Measurements[Test_Calibration_Data[i]]
> Only if that location happens to be 0xFFFF, then it is okay.
>
> Read you code again, and THINK!
>
> --- In m...@yahoogroups.com, "e.tury"
> >
> > I'll have to think that through. (May take a while!)
> >
> > I am in touch with a TI guy who emailed me some flash write code
> > using indirection (pointers). The big difference I see is that he
> > turns on the flash programmer clock, etc. THEN does a whole array
> > write, then turns flash writing off. Whereas my writes are
internal
> > to the loop, so the flash stuff gets cycled on and off for each
> > write, instead of once per bunch o' writes.
> >
> > I appreciate your input.
> >
> > Edd
> >
> > --- In m...@yahoogroups.com, "old_cow_yellow"
> > wrote:
> > >
> > > So, [offset]=2*[index]
> > > Thus offset is always even, even if [index] is odd.
> > > (; Pardon my English ;)
> > >
> > > I think we are both barking up the wrong trees.
> > >
> > > How about change:
> > >
> > > if(Measurements[i] == 0xFFFF)
> > > ...
> > >
> > > into:
> > >
> > > if(Measurements[Test_Calibration_Data[i]] == 0xFFFF)
> > > ...
> > >
> > > Any bird up there?
> > >
> > > --- In m...@yahoogroups.com, "e.tury"
> > > >
> > > >
> > > > Now that I can count by 2, I'm back to debugging the
original
> > flash
> > > > write problem: skipping a write for no (apparent) reason.
> > > >
> > > > I've padded my table with consecutive addresses as shown
below.
> > > >
> > > > The flash gets erased before every attempt, and the 0xFFFFs
> > always show
> > > > up in the debug window when I check.
> > > >
> > > > Running the loop twice doesn't fill in the blanks. Another
> > assembled
> > > > board shows exactly the same bad writes.
> > > >
> > > > I'm going nuts.
> > > >
> > > > Any suggestions for more experiments would be appreciated.
> > > >
> > > > I am using IAR Workbench 4.0;
> > > >
> > > > code:
> > > >
> > > > #pragma location = 0x4000
> > > >
> > > > const uint16 Measurements[4096];
> > > >
> > > > const uint16 Test_Calibration_Data[] = {
> > > > 3453,0,
> > > > .........
> > > > .........
> > > >
> > > > 1198,700,
> > > > 1194,701,
> > > > 1191,702,
> > > > 1189,703,
> > > > 1188,704,//test
> > > > 1187,704,//test
> > > > 1186,704,
> > > > 1185,704,//test
> > > > 1184,704,//test
> > > > 1183,704,//test
> > > > 1182,705,//test
> > > > 1181,705,
> > > > 1180,706,//test
> > > > 1179,706,//test
> > > > 1178,706,//test
> > > > 1177,706,
> > > > 1176,706,//test
> > > > 1175,706,//test
> > > > 1174,707,
> > > > 1173,707,//test
> > > > 1172,707,//test
> > > > 1171,708,
> > > > 1167,709,
> > > > .....
> > > > .....
> > > >
> > > >
> > > > };
> > > >
> > > > 00491E FFFF FFFF
> > > > 004922 FFFF FFFF
> > > > 004926 02C4
> > > > 004928 02C3
> > > > 00492A 02C3
> > > > 00492C 02C3
> > > > 00492E FFFF 02C2 //bad write @ 1175
> > > > 004932 02C2 //706
> > > > 004934 02C2
> > > > 004936 02C2
> > > > 004938 FFFF 02C1 //bad write @ 1180
> > > > 00493C 02C1
> > > > 00493E 02C0
> > > > 004940 FFFF 02C0 //bad write @1184
> > > > 004944 FFFF 02C0 //bad write @ 1186
> > > > 004948 FFFF 02BF
> > > > 00494C FFFF 02BE
> > > > 004950 FFFF FFFF
> > > > 004954 02BD FFFF
> > > > 004958 FFFF FFFF
> > > > 00495C 02BC FFFF
> > > > 004960 FFFF FFFF
> > > > 004964 FFFF FFFF
> > > > 004968 FFFF 02BA
> > > > 00496C FFFF FFFF
> > > > 004970 FFFF FFFF
> > > >
> > > >
> > > > for (i=0; i<2002; i+=2)
> > > > {
> > > >
> > > > if(Measurements[i] == 0xFFFF)
> > > > {
> > > >
> > > > Flash_Write_Word((int16*) &(Measurements
[Test_Calibration_Data
> > [i]]),
> > > > Test_Calibration_Data[i+1]);
> > > >
> > > >
> > > > }
> > > >
> > > > void Flash_Write_Word(int16 *data_pointer, int16 word)
> > > > {
> > > >
> > > >
> > > > FCTL3 = FWKEY; // Clear LOCK
> > > > FCTL1 = FWKEY + WRT; // Enable WRITE
> > > >
> > > > *data_pointer = word; // program Flash word
> > > >
> > > > FCTL1 = FWKEY; // Clear WRITE
> > > > FCTL3 = FWKEY + LOCK; // Set LOCK
> > > >
> > > > }
> > > >
> > > >
> > > > Edd
> > > >
> > >
>
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )