Issue regarding difference between bytes coping on flash memory of LPC1767

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Issue regarding difference between bytes coping on flash memory of LPC1767

Jump to solution
856 Views
bilalqureshi_ep
Contributor II

I have task to develop a software for writing hex content to flash, of course there are tools for it but the tools had issues so i had to make my own software for it but first i need to understand it (for understanding purpose i am using flashmagic software for now).

The issue is that its says in NXP LPCxx document that The length of any
UU-encoded line should not exceed 61 characters (bytes) i.e. it can hold 45 data bytes.
The receiver should compare it with the check-sum of the received bytes.

  1. My first question is that it is not mentioned in document or i am having understanding issue that will the after writing data in reader will the checksum will be send along it or after it separately.
  2. My second question is it says in document that 20 UU encoded lines are sent so basically does it mean 20 X 61 = 1220 bytes or 45 X 20 = 900 bytes? and is that 1 byte is for checksum?
  3. What is formula to calculate checksum?
  4. My third question is that i used flashmagic tool for now if 1220 bytes per cycle are sent to reader as mentioned in question 2, but the the amount of bytes that are copied from RAM to flash are 1024 bytes per cycle that are less than 1220 bytes or 900 bytes are the valid case. How is this possible that number of bytes that are copied to flash are less than 1220 byes.

Thanks in advance,

M.Bilal

Labels (1)
1 Solution
629 Views
Alexis_A
NXP TechSupport
NXP TechSupport

Dear bilalqureshi.epic@gmail.com‌,

I will try to answer your question the best I can:

The checksum will be send it after all the package, using the flash magic as a reference, this send 512 bytes for each command to write in RAM (this is implementation of the flash magic, it could be until 900 bytes), this is calculated adding the raw data of all the 512 bytes:

For example, if all the 512 bytes are 0xFF the checksum will be 130560:

pastedImage_1.png

Remember that the encoding that is used is the UU-encoded so the packages will have up to 61 bytes, (1 of the size of the package + 32 and the payload encoded) each 4 bytes will represent 3 bytes of raw data. That's why the payload raw data is 45.

I hope this information helps you.

Best Regards,

Alexis Andalon

View solution in original post

2 Replies
630 Views
Alexis_A
NXP TechSupport
NXP TechSupport

Dear bilalqureshi.epic@gmail.com‌,

I will try to answer your question the best I can:

The checksum will be send it after all the package, using the flash magic as a reference, this send 512 bytes for each command to write in RAM (this is implementation of the flash magic, it could be until 900 bytes), this is calculated adding the raw data of all the 512 bytes:

For example, if all the 512 bytes are 0xFF the checksum will be 130560:

pastedImage_1.png

Remember that the encoding that is used is the UU-encoded so the packages will have up to 61 bytes, (1 of the size of the package + 32 and the payload encoded) each 4 bytes will represent 3 bytes of raw data. That's why the payload raw data is 45.

I hope this information helps you.

Best Regards,

Alexis Andalon

629 Views
bilalqureshi_ep
Contributor II

Thank You @Alexis Andalon, i applied what you said and getting correct uu-encoding as that of flash magic, the only issue i am facing right now is checksum of first and last 512 bytes, i am not sure what is wrong with first 512 bytes checksum but some how i think there is padding in last checksum of "F". for example for first 512 bytes i get 34964 checksum of raw data whereas it should be 35644, after this all the checksum are fine except the last one. Can you kindly help me with this one as well according to your knowledge. 

0 Kudos