Verify CRC32 results in error about cc2538-bsl HOT 4 CLOSED

Looks like something is going wrong indeed, the calculation of the CRC seems to be correct the first time, but the second time the chip is giving you a different value.

What happens when you do a read and compare the read hex file with the original?

Could it be that your code altered its own contents in between the flash and then the second verification?

from cc2538-bsl.

Thank's for the fast reply :-). Meanwhile I tested with another firmware-image, but the same issue here as well.

Could it be that your code altered its own contents in between the flash and then the second verification?

I do not know - It's an image of @Koenkk resp. slae.sh.

Here are the results of the read followed by a CRC32-check, which results in different checksums :-( Maybe the image works as designed despite the crc32-difference? I will try to check this out with @Koenkk.

Read from CC2652RB-Stick followed by a CRC32-check:

$ sudo cc2538-bsl/cc2538-bsl.py -r -l 360448 -p /dev/ttyUSB0 -b 115200 znp_CC2652RB_20200715-from-stick.bin_ 

Opening port /dev/ttyUSB0, baud 115200
Connecting to target...
CC1350 PG2.0 (7x7mm): 352KB Flash, 20KB SRAM, CCFG.BL_CONFIG at 0x00057FD8
Primary IEEE Address: 00:12:4B:00:23:93:37:48
Reading 360448 bytes starting at address 0x0
    Read done                                

$ ls -l
insgesamt 1108
drwxr-xr-x 4 pi   pi     4096 Nov 27 18:48 cc2538-bsl
-rw-r--r-- 1 pi   pi   404980 Jul  8 19:52 CC2652RB_coordinator_20210708.hex
-rw-r--r-- 1 pi   pi   360448 Jul 22  2020 znp_CC2652RB_20200715.bin
-rw-r--r-- 1 root root 360448 Nov 29 18:03 znp_CC2652RB_20200715-from-stick.bin


$ rhash --simple --crc32 *.bin
47570b28  znp_CC2652RB_20200715.bin
747f9c98  znp_CC2652RB_20200715-from-stick.bin

from cc2538-bsl.

I finally succeeded in bringing the application on the stick to cooperate with zigbee2mqtt by @Koenkk :-) So the flashing must have been correct, otherwise it would not run, right?
The question, why the checksums are different is still unsolved, but as long as the software runs...

So, thank's a lot for your help. This issues can be closed from my point of view.

from cc2538-bsl.

Seeing the same size but different hashes on the read operation, it does look like the code altered its own flash in some way. That would be my best guess, since the crc does match on the write operation.

You could do a diff between both and check which sections are different, and look what those sections mean.

I'll close this one for now since it looks like the script isn't malfunctioning.
Anyone feel free to re-open if you discover otherwise.

Thanks for the report @charraeus

from cc2538-bsl.