0

I'm trying to implement checksum for some commands to communicate with internal ROM using uart. eg: commad code 0x02 + 0xFD will give id of the device. How 0xFD is calculated?

From the data sheet:
All communications from the programming tool (PC) to the device are verified by:
1. checksum: received blocks of data bytes are XORed. A byte containing the computed
XOR of all previous bytes is added to the end of each communication (checksum byte).
By XORing all received bytes, data + checksum, the result at the end of the packet
must be 0x00
2. for each command the host sends a byte and its complement (XOR = 0x00)
3. UART: parity check active (even parity)
old_timer
  • 69,149
  • 8
  • 89
  • 168
SamForiYana
  • 53
  • 1
  • 2
  • 11
  • first off what is 0x02 xor 0xFD? certainly not zero... – old_timer Apr 15 '18 at 23:07
  • 0x02 = 0b00000010 0xFD = 0b11111101, you see the pattern? – old_timer Apr 15 '18 at 23:12
  • The command 0x02 should be followed by checksum in above case it is 0xFD. But in data sheet it was mentioned command or data + checksum must be 0. I didnt understand it @old_timer – SamForiYana Apr 15 '18 at 23:17
  • the command is not data so they can wiggle out of that one. The command and its complement do not xor to equal 0. for the most part ignore that section, docs are not always right, get used to it... – old_timer Apr 15 '18 at 23:32
  • notice all the flow charts, when do they specify the checksum? – old_timer Apr 15 '18 at 23:32
  • not for the command, for the command you mentioned you send 0x02 then 0xFD (the ones complement 0x02^0xFF = 0xFD) or just read the manual to see the 0xFD, dont necessarily need to compute it. and then wait for the ack from the mcu – old_timer Apr 15 '18 at 23:33
  • now ones that have data like the write memory command you send 0x31 0xCE because it says so, then you wait for the ack THEN you send the address plus a byte of "checksum" which is a bad term to use, but in that case that 5th byte is the xor of the prior 4. then wait for ack/nack then another set of bytes as described then the "checksum" the xor of the prior bytes for that series. – old_timer Apr 15 '18 at 23:35
  • working at this level 1) the docs are never perfect 2) hacking is required 3) in this case there is enough information to figure it out knowing 1 and 2 and what is in the manual. – old_timer Apr 15 '18 at 23:35
  • 4) there is enough example code out there to see how it really works – old_timer Apr 15 '18 at 23:37
  • just take it one step at a time send 0x7F wait for the 0x79, you have made huge progress at that point. then use the get command, send 0x00, 0xFF and examine all the bytes that come back. get version and get id. – old_timer Apr 15 '18 at 23:43
  • it should have said the xor of the command and its complement = 0xFF. the command and its (ones) complement are sent separately from blobs of data that have an additional "checksum" byte. – old_timer Apr 15 '18 at 23:45
  • @old_timer so far I have created routines todo the same for ACK and get version with commands specified in the flow chart. I looking forward to implement the write and read operations on memory for which I ran into this checksum confusion Thank you for your details. – SamForiYana Apr 15 '18 at 23:50
  • just follow the flowchart in the same manual. where they say checksum byte is when you do the xor thing... – old_timer Apr 15 '18 at 23:51
  • actually that is not true either. looking at the flowchart and my code for a read, the command is command and complement. the address is the address plus a byte that is xors of the bytes of the address. the number of bytes appears to be bytes-1 and the complement of that. they they send the data. now how long has it been since I used the read side of that code? dont remember, and did it work? probably but dont remember. – old_timer Apr 15 '18 at 23:56
  • for writes the command is as described command and complement, wait for ack. the address is four bytes plus the xor of those bytes, wait for ack. then the number of bytes is n-1 so if you write one 32 bit word, then send a 3 the four bytes msbyte first, then the xor of those 5 bytes. wait for ack. – old_timer Apr 15 '18 at 23:58
  • from my experience the parts either support erase or extended erase but not both, you have to look at what comes back from the get command. I write 32 bits at a time, just because, dont remember why, but looking the stm32lxxx low power parts looks like I had to switch to 64 bits at a time to get those to work. – old_timer Apr 16 '18 at 00:01
  • @old_timer for read and write protection the sequence after sending the number of sectors(n-1) as 1 bytes, its expects to send sector codes, what are these sector codes and where are they defined? im using stm32F071 i has 31 sectors with 2pages/sector and 2kb/page flash size 128kb – SamForiYana Apr 16 '18 at 08:26
  • you are trying to write protect? is it failing to do an erase? why are you messing with protection? I have used the write unprotect, and it worked but not as the manual described the write unprotect on the device I used, you sent the command I dont think it responded, you power cycled then it was good you could erase. I have not used the protection or unprotect other than that. – old_timer Apr 16 '18 at 11:37
  • @SamForiYana, post a link to the datasheet please. I'd like to take a look. – Gabriel Staples Apr 17 '18 at 00:14
  • @GabrielStaples stm32 AN3155 uart protocol for bootloader https://www.google.de/url?sa=t&source=web&rct=j&url=http://www.st.com/resource/en/application_note/cd00264342.pdf&ved=2ahUKEwjF6a6xvcDaAhVrP5oKHdNhBs4QFjAAegQIARAB&usg=AOvVaw3ct0AapZkmN-MbtEYCMPlf – SamForiYana Apr 17 '18 at 04:36
  • @old_timer I havent implemented erase yet, but I assume after write or read unprotect it should be protected again from corruption of data due unwanted electrical glitches. At least that is the procedure I have noticed in HAL api while I was working on flash read and write. – SamForiYana Apr 17 '18 at 04:48

1 Answers1

0

If i understood you well. Then that means for every byte there are seven bits of data, 1 bit parity, like if you want to send '1' which is 0x31 (0b00110001), then even parity+7 Data bits change it into 0xB1 (0x10110001), now you have to xor this value to the next byte you want to send.Lets say you want to send 100 Bytes, then you have to have temp register that will keep xor'ing each byte, like temp_Byte =^ Byte_1; temp_byte =^ Byte_2 and so on. After sending 100th byte (which is last byte of your actual data), you also have to send Temp_byte. The PC will check it by xor'ing all 101 bytes and if result is 0, then it thinks data received nicely.

BetaEngineer
  • 3
  • 6