CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

write_program_memory() with 3.204

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
UKH
Guest







write_program_memory() with 3.204
PostPosted: Tue Jul 13, 2004 1:45 am     Reply with quote

Hello together,

few days ago I've re-compiled my current project (PIC18F6680) with
the PCH-version 3.204. An important part of this program is a bootloader
which is using the CCS-Function write_program_memory().

Up to this moment I've used 3.189 without a problem. After several hours of testing I found that write_program_memory() destroy's area's
of code which should surely not be programmed by this function.

All observations related with this was found with my standard-setting of
compiler-switches which are set to "+DF +LN +T -A +M -Z +Y=9 +EA"
inside MPLAB.

Further observations with the same code and +Y=8 (Optimizing) shows
that my code runs correctly, -> up to now, hope that all others is OK.

As a conclusion of this I decide to turn back to 3.189.

Has somebody made similiar exeriences ?

Would be nice to hear something.

Uwe Koch
Ttelmah
Guest







Re: write_program_memory() with 3.204
PostPosted: Tue Jul 13, 2004 1:59 am     Reply with quote

UKH wrote:
Hello together,

few days ago I've re-compiled my current project (PIC18F6680) with
the PCH-version 3.204. An important part of this program is a bootloader
which is using the CCS-Function write_program_memory().

Up to this moment I've used 3.189 without a problem. After several hours of testing I found that write_program_memory() destroy's area's
of code which should surely not be programmed by this function.

All observations related with this was found with my standard-setting of
compiler-switches which are set to "+DF +LN +T -A +M -Z +Y=9 +EA"
inside MPLAB.

Further observations with the same code and +Y=8 (Optimizing) shows
that my code runs correctly, -> up to now, hope that all others is OK.

As a conclusion of this I decide to turn back to 3.189.

Has somebody made similiar exeriences ?

Would be nice to hear something.

Uwe Koch

Write_program_memory, can write _anywhere_ in memory, that has not been protected by the fuses. What address are you trying to proram?. What are the code addresses of your code.
Post a small example, which will allow us to see whether this is a program fault, or a problem with the compiler version.

Best Wishes
UKH
Guest







PostPosted: Tue Jul 13, 2004 2:52 am     Reply with quote

OK, no problem:

basic fucntions were used from "theByteFactory.com"-Bootloader.
I have never analysed the whole program-memory which were loaded
during bootload-function but:
At the very end the reset-vector-address of the loaded program should be
written to a location inside the bootloader. During this it happens:


// Download is complete - Modify the loader with the application reset vector
// NOTE: If overall_success is FALSE from the firmware download then the vector write will not occur
for (main_temp_U8 = 0; ((main_temp_U8 <= 2) && (overall_success == TRUE)); main_temp_U8 += 2)
{
overall_success = kind_write_verify_program_eeprom ((reset_vector_location + main_temp_U8), temp_reset_vector[(main_temp_U8 >> 1)]);
}

After this for-loop I take at look at the program-memory:

29375 0E57C EF47 GOTO 0x428e
29376 0E57E F021 NOP
29377 0E580 FFFF NOP
29378 0E582 FFFF NOP
29379 0E584 FFFF NOP
29380 0E586 FFFF NOP
29381 0E588 FFFF NOP
29382 0E58A FFFF NOP
29383 0E58C FFFF NOP
29384 0E58E FFFF NOP
29385 0E590 FFFF NOP
29386 0E592 FFFF NOP
29387 0E594 FFFF NOP
29388 0E596 FFFF NOP
29389 0E598 FFFF NOP
29390 0E59A FFFF NOP
29391 0E59C FFFF NOP
29392 0E59E FFFF NOP
29393 0E5A0 FFFF NOP
29394 0E5A2 FFFF NOP
29395 0E5A4 FFFF NOP
29396 0E5A6 FFFF NOP
29397 0E5A8 FFFF NOP
29398 0E5AA FFFF NOP
29399 0E5AC FFFF NOP
29400 0E5AE FFFF NOP
29401 0E5B0 FFFF NOP
29402 0E5B2 FFFF NOP
29403 0E5B4 FFFF NOP
29404 0E5B6 FFFF NOP
29405 0E5B8 FFFF NOP
29406 0E5BA FFFF NOP
29407 0E5BC FFFF NOP
29408 0E5BE FFFF NOP
29409 0E5C0 FFFF NOP
29410 0E5C2 FFFF NOP
29411 0E5C4 FFFF NOP
29412 0E5C6 FFFF NOP
29413 0E5C8 FFFF NOP
29414 0E5CA FFFF NOP
29415 0E5CC FFFF NOP
29416 0E5CE FFFF NOP
29417 0E5D0 FFFF NOP
29418 0E5D2 FFFF NOP
29419 0E5D4 FFFF NOP
29420 0E5D6 FFFF NOP
29421 0E5D8 FFFF NOP
29422 0E5DA FFFF NOP
29423 0E5DC FFFF NOP
29424 0E5DE FFFF NOP
29425 0E5E0 FFFF NOP
29426 0E5E2 FFFF NOP
29427 0E5E4 FFFF NOP
29428 0E5E6 FFFF NOP
29429 0E5E8 FFFF NOP
29430 0E5EA FFFF NOP
29431 0E5EC FFFF NOP
29432 0E5EE FFFF NOP
29433 0E5F0 FFFF NOP
29434 0E5F2 FFFF NOP
29435 0E5F4 FFFF NOP
29436 0E5F6 FFFF NOP
29437 0E5F8 FFFF NOP
29438 0E5FA FFFF NOP
29439 0E5FC FFFF NOP
29440 0E5FE FFFF NOP
29441 0E600 FFFF NOP
29442 0E602 FFFF NOP
29443 0E604 FFFF NOP
29444 0E606 FFFF NOP
29445 0E608 FFFF NOP
29446 0E60A FFFF NOP
29447 0E60C FFFF NOP
29448 0E60E FFFF NOP
29449 0E610 FFFF NOP
29450 0E612 FFFF NOP
29451 0E614 FFFF NOP
29452 0E616 FFFF NOP
29453 0E618 FFFF NOP
29454 0E61A FFFF NOP
29455 0E61C FFFF NOP
29456 0E61E FFFF NOP
29457 0E620 FFFF NOP
29458 0E622 FFFF NOP
29459 0E624 FFFF NOP
29460 0E626 FFFF NOP
29461 0E628 FFFF NOP
29462 0E62A FFFF NOP
29463 0E62C FFFF NOP
29464 0E62E FFFF NOP
29465 0E630 FFFF NOP
29466 0E632 FFFF NOP
29467 0E634 FFFF NOP
29468 0E636 FFFF NOP
29469 0E638 FFFF NOP
29470 0E63A FFFF NOP
29471 0E63C FFFF NOP
29472 0E63E FFFF NOP
29473 0E640 F091 NOP
29474 0E642 9EF2 BCF INTCON, 0x7, ACCESS
29475 0E644 6AAA CLRF EEADRH, ACCESS

Sorry for this big block, but I want to show the end of the empty-code

The reset-vector-address of the loaded program was programed correctly
(0x428e) but a "big" erased area of code is following them.

The function kind_write_..... is taken from "theByteFactory.com"-Bootloader too. By the way it works fine:

#separate
BOOLEAN kind_write_verify_program_eeprom (U32BIT address, U16BIT data)
{ // It's called FLASH but it has all the properties of EEPROM, even write cycle delay
U16BIT current_data;
U16BIT ee_block[32]; // Program EEPROM must be modified in blocks of 64 bytes
U32BIT ee_block_address; // Contains the address of the first byte of the block
U8BIT ee_block_index; // Contains the offset to the data to be modified


current_data = read_program_eeprom (address); // Get the data that is currently at the target address
if (current_data != data)
{ // Do not write the eeprom if the data is already there
// This will reduce wear on the memory and improve execution speed
ee_block_address = address & 0xFFFFFFC0; // 0b11111111111111111111111111000000
ee_block_index = (address & 0x0000003F) >> 1; // 0b00000000000000000000000000111111
// The index is divided by 2 because the data is 2 bytes wide
read_program_memory (ee_block_address, ee_block, 64); // Read the entire EEPROM block (64 bytes)
ee_block[ee_block_index] = data; // Modify the block with the new data
write_program_memory (ee_block_address, ee_block, 64); // Write the entire EEPROM block
// NOTE: Program EEPROM is automatically erased when full blocks are written, otherwise it is not

current_data = read_program_eeprom (address); // Get the data that is NOW at the target address
if (current_data != data)
{ // The write to program memory has failed
return (FALSE); // Return failure flag
}
} // The new data was successfully written
return (TRUE); // Return success flag
}

See you soon

Uwe Koch
UKH
Guest







write_program_memory() with 3.204
PostPosted: Tue Jul 13, 2004 2:53 am     Reply with quote

OK, no problem:

basic fucntions were used from "theByteFactory.com"-Bootloader.
I have never analysed the whole program-memory which were loaded
during bootload-function but:
At the very end the reset-vector-address of the loaded program should be
written to a location inside the bootloader. During this it happens:


// Download is complete - Modify the loader with the application reset vector
// NOTE: If overall_success is FALSE from the firmware download then the vector write will not occur
for (main_temp_U8 = 0; ((main_temp_U8 <= 2) && (overall_success == TRUE)); main_temp_U8 += 2)
{
overall_success = kind_write_verify_program_eeprom ((reset_vector_location + main_temp_U8), temp_reset_vector[(main_temp_U8 >> 1)]);
}

After this for-loop I take at look at the program-memory:

29375 0E57C EF47 GOTO 0x428e
29376 0E57E F021 NOP
29377 0E580 FFFF NOP
29378 0E582 FFFF NOP
29379 0E584 FFFF NOP
29380 0E586 FFFF NOP
29381 0E588 FFFF NOP
29382 0E58A FFFF NOP
29383 0E58C FFFF NOP
29384 0E58E FFFF NOP
29385 0E590 FFFF NOP
29386 0E592 FFFF NOP
29387 0E594 FFFF NOP
29388 0E596 FFFF NOP
29389 0E598 FFFF NOP
29390 0E59A FFFF NOP
29391 0E59C FFFF NOP
29392 0E59E FFFF NOP
29393 0E5A0 FFFF NOP
29394 0E5A2 FFFF NOP
29395 0E5A4 FFFF NOP
29396 0E5A6 FFFF NOP
29397 0E5A8 FFFF NOP
29398 0E5AA FFFF NOP
29399 0E5AC FFFF NOP
29400 0E5AE FFFF NOP
29401 0E5B0 FFFF NOP
29402 0E5B2 FFFF NOP
29403 0E5B4 FFFF NOP
29404 0E5B6 FFFF NOP
29405 0E5B8 FFFF NOP
29406 0E5BA FFFF NOP
29407 0E5BC FFFF NOP
29408 0E5BE FFFF NOP
29409 0E5C0 FFFF NOP
29410 0E5C2 FFFF NOP
29411 0E5C4 FFFF NOP
29412 0E5C6 FFFF NOP
29413 0E5C8 FFFF NOP
29414 0E5CA FFFF NOP
29415 0E5CC FFFF NOP
29416 0E5CE FFFF NOP
29417 0E5D0 FFFF NOP
29418 0E5D2 FFFF NOP
29419 0E5D4 FFFF NOP
29420 0E5D6 FFFF NOP
29421 0E5D8 FFFF NOP
29422 0E5DA FFFF NOP
29423 0E5DC FFFF NOP
29424 0E5DE FFFF NOP
29425 0E5E0 FFFF NOP
29426 0E5E2 FFFF NOP
29427 0E5E4 FFFF NOP
29428 0E5E6 FFFF NOP
29429 0E5E8 FFFF NOP
29430 0E5EA FFFF NOP
29431 0E5EC FFFF NOP
29432 0E5EE FFFF NOP
29433 0E5F0 FFFF NOP
29434 0E5F2 FFFF NOP
29435 0E5F4 FFFF NOP
29436 0E5F6 FFFF NOP
29437 0E5F8 FFFF NOP
29438 0E5FA FFFF NOP
29439 0E5FC FFFF NOP
29440 0E5FE FFFF NOP
29441 0E600 FFFF NOP
29442 0E602 FFFF NOP
29443 0E604 FFFF NOP
29444 0E606 FFFF NOP
29445 0E608 FFFF NOP
29446 0E60A FFFF NOP
29447 0E60C FFFF NOP
29448 0E60E FFFF NOP
29449 0E610 FFFF NOP
29450 0E612 FFFF NOP
29451 0E614 FFFF NOP
29452 0E616 FFFF NOP
29453 0E618 FFFF NOP
29454 0E61A FFFF NOP
29455 0E61C FFFF NOP
29456 0E61E FFFF NOP
29457 0E620 FFFF NOP
29458 0E622 FFFF NOP
29459 0E624 FFFF NOP
29460 0E626 FFFF NOP
29461 0E628 FFFF NOP
29462 0E62A FFFF NOP
29463 0E62C FFFF NOP
29464 0E62E FFFF NOP
29465 0E630 FFFF NOP
29466 0E632 FFFF NOP
29467 0E634 FFFF NOP
29468 0E636 FFFF NOP
29469 0E638 FFFF NOP
29470 0E63A FFFF NOP
29471 0E63C FFFF NOP
29472 0E63E FFFF NOP
29473 0E640 F091 NOP
29474 0E642 9EF2 BCF INTCON, 0x7, ACCESS
29475 0E644 6AAA CLRF EEADRH, ACCESS

Sorry for this big block, but I want to show the end of the empty-code

The reset-vector-address of the loaded program was programed correctly
(0x428e) but a "big" erased area of code is following them.

The function kind_write_..... is taken from "theByteFactory.com"-Bootloader too. By the way it works fine:

#separate
BOOLEAN kind_write_verify_program_eeprom (U32BIT address, U16BIT data)
{ // It's called FLASH but it has all the properties of EEPROM, even write cycle delay
U16BIT current_data;
U16BIT ee_block[32]; // Program EEPROM must be modified in blocks of 64 bytes
U32BIT ee_block_address; // Contains the address of the first byte of the block
U8BIT ee_block_index; // Contains the offset to the data to be modified


current_data = read_program_eeprom (address); // Get the data that is currently at the target address
if (current_data != data)
{ // Do not write the eeprom if the data is already there
// This will reduce wear on the memory and improve execution speed
ee_block_address = address & 0xFFFFFFC0; // 0b11111111111111111111111111000000
ee_block_index = (address & 0x0000003F) >> 1; // 0b00000000000000000000000000111111
// The index is divided by 2 because the data is 2 bytes wide
read_program_memory (ee_block_address, ee_block, 64); // Read the entire EEPROM block (64 bytes)
ee_block[ee_block_index] = data; // Modify the block with the new data
write_program_memory (ee_block_address, ee_block, 64); // Write the entire EEPROM block
// NOTE: Program EEPROM is automatically erased when full blocks are written, otherwise it is not

current_data = read_program_eeprom (address); // Get the data that is NOW at the target address
if (current_data != data)
{ // The write to program memory has failed
return (FALSE); // Return failure flag
}
} // The new data was successfully written
return (TRUE); // Return success flag
}

See you soon

Uwe Koch
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group