Re: [Openocd-development] Problem with OpenOCD 0.5.0-rc1 and STM32 verify_image
On Fri, Jul 22, 2011 at 4:57 PM, Freddie Chopin freddie_cho...@op.plwrote: On 2011-07-21 23:02, Andreas Fritiofson wrote: However I can't explain Freddie's reproduced failures. Maybe post the hex files (matching, slightly different and very different) and I can see if I can take a closer look at it? I attach three .hex files (compressed). From what I see, there's no info about anything in RAM... According to objdump, the completely different hex file is located in RAM: arm-none-eabi-objdump -x verify_image/original.hex verify_image/almost_the_same.hex verify_image/completely_different.hex verify_image/original.hex: file format ihex verify_image/original.hex architecture: UNKNOWN!, flags 0x: start address 0x08000131 Sections: Idx Name Size VMA LMA File off Algn 0 .sec1 74c0 0800 0800 0011 2**0 CONTENTS, ALLOC, LOAD SYMBOL TABLE: no symbols verify_image/almost_the_same.hex: file format ihex verify_image/almost_the_same.hex architecture: UNKNOWN!, flags 0x: start address 0x08000131 Sections: Idx Name Size VMA LMA File off Algn 0 .sec1 74c0 0800 0800 0011 2**0 CONTENTS, ALLOC, LOAD SYMBOL TABLE: no symbols verify_image/completely_different.hex: file format ihex verify_image/completely_different.hex architecture: UNKNOWN!, flags 0x: start address 0x2131 Sections: Idx Name Size VMA LMA File off Algn 0 .sec1 0324 2000 2000 0011 2**0 CONTENTS, ALLOC, LOAD SYMBOL TABLE: no symbols ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem with OpenOCD 0.5.0-rc1 and STM32 verify_image
On 2011-07-22 17:30, Andreas Fritiofson wrote: According to objdump, the completely different hex file is located in RAM: Oops (; Indeed it is - I forgot that it's from a project I recently experimented on... Sorry for the mess (; So - I cannot confirm the issue, it works for me with 0.4.0 - 0.5.0-rc1. Magnus - could you explain your issue in greater detail? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem with OpenOCD 0.5.0-rc1 and STM32 verify_image
I can partially confirm... Tested with 0.5.0-rc1 Comparing with right image works fine: verify_image c://stm32_blink_led.bin 0x800 verified 29888 bytes in 0.468750s (62.267 KiB/s) verify_image c://stm32_blink_led.bin verified 29888 bytes in 0.484375s (60.258 KiB/s) verify_image c://stm32_blink_led.hex verified 29888 bytes in 0.50s (58.375 KiB/s) verify_image c://stm32_blink_led.elf verified 29888 bytes in 0.921875s (31.661 KiB/s) Comparing with almost right image (compilation date inside has changed) works fine too: verify_image c://stm32_blink_led.elf checksum mismatch - attempting binary compare diff 0 address 0x08006d26. Was 0x32 instead of 0x31 diff 1 address 0x08006d27. Was 0x31 instead of 0x38 diff 2 address 0x08006d29. Was 0x34 instead of 0x32 diff 3 address 0x08006d2c. Was 0x35 instead of 0x34 diff 4 address 0x08006d2d. Was 0x34 instead of 0x36 diff 5 address 0x08006d34. Was 0x31 instead of 0x32 No more differences found. in procedure 'verify_image' verify_image c://stm32_blink_led.hex checksum mismatch - attempting binary compare diff 0 address 0x08006d26. Was 0x32 instead of 0x31 diff 1 address 0x08006d27. Was 0x31 instead of 0x38 diff 2 address 0x08006d29. Was 0x34 instead of 0x32 diff 3 address 0x08006d2c. Was 0x35 instead of 0x34 diff 4 address 0x08006d2d. Was 0x34 instead of 0x36 diff 5 address 0x08006d34. Was 0x31 instead of 0x32 No more differences found. in procedure 'verify_image' verify_image c://stm32_blink_led.bin checksum mismatch - attempting binary compare diff 0 address 0x6d26. Was 0x32 instead of 0x31 diff 1 address 0x6d27. Was 0x31 instead of 0x38 diff 2 address 0x6d29. Was 0x34 instead of 0x32 diff 3 address 0x6d2c. Was 0x35 instead of 0x34 diff 4 address 0x6d2d. Was 0x34 instead of 0x36 diff 5 address 0x6d34. Was 0x31 instead of 0x32 No more differences found. in procedure 'verify_image' verify_image c://stm32_blink_led.bin 0x800 checksum mismatch - attempting binary compare diff 0 address 0x08006d26. Was 0x32 instead of 0x31 diff 1 address 0x08006d27. Was 0x31 instead of 0x38 diff 2 address 0x08006d29. Was 0x34 instead of 0x32 diff 3 address 0x08006d2c. Was 0x35 instead of 0x34 diff 4 address 0x08006d2d. Was 0x34 instead of 0x36 diff 5 address 0x08006d34. Was 0x31 instead of 0x32 No more differences found. in procedure 'verify_image' However... when checking against something completely wrong (almost completely different code) strange things happen. When checking against bin, everything is as expected, but when checking against hex or elf: verify_image c://stm32_blink_led.hex checksum mismatch - attempting binary compare diff 0 address 0x2000. Was 0x02 instead of 0x28 diff 1 address 0x2001. Was 0x46 instead of 0x03 ... diff 126 address 0x2097. Was 0x00 instead of 0x20 diff 127 address 0x2098. Was 0x00 instead of 0x15 More than 128 errors, the rest are not printed. in procedure 'verify_image' verify_image c://stm32_blink_led.elf checksum mismatch - attempting binary compare diff 0 address 0x2000. Was 0x02 instead of 0x28 diff 1 address 0x2001. Was 0x46 instead of 0x03 ... diff 126 address 0x2097. Was 0x00 instead of 0x20 diff 127 address 0x2098. Was 0x00 instead of 0x15 More than 128 errors, the rest are not printed. in procedure 'verify_image' If you specify address it is treated as an offset from beginning of RAM... verify_image c://stm32_blink_led.hex 0x2000 checksum mismatch - attempting binary compare diff 0 address 0x20002000. Was 0x02 instead of 0x28 diff 1 address 0x20002001. Was 0x02 instead of 0x03 ... diff 126 address 0x2000207f. Was 0x37 instead of 0x20 diff 127 address 0x20002080. Was 0x10 instead of 0x15 More than 128 errors, the rest are not printed. in procedure 'verify_image' verify_image c://stm32_blink_led.hex 0x4000 checksum mismatch - attempting binary compare diff 0 address 0x20004000. Was 0x8a instead of 0x28 diff 1 address 0x20004001. Was 0xb9 instead of 0x03 ... diff 126 address 0x2000407e. Was 0x52 instead of 0x00 diff 127 address 0x2000407f. Was 0x96 instead of 0x20 More than 128 errors, the rest are not printed. in procedure 'verify_image' verify_image c://stm32_blink_led.hex 0x8000 stm32.cpu -- clearing lockup after double fault error executing cortex_m3 crc algorithm JTAG-DP STICKY ERROR MEM_AP_CSW 0x2352, MEM_AP_TAR 0x20008004 JTAG-DP STICKY ERROR MEM_AP_CSW 0x2352, MEM_AP_TAR 0x20008004 Block read error address 0x20008000 in procedure 'verify_image' (it's the same for elf). So sometimes OpenOCD starts the check in completely wrong location... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem with OpenOCD 0.5.0-rc1 and STM32 verify_image
Freddie Chopin freddie_chopin@... writes: I can partially confirm... Tested with 0.5.0-rc1 Comparing with right image works fine: Comparing with almost right image (compilation date inside has changed) works fine too: However... when checking against something completely wrong (almost completely different code) strange things happen. When checking against bin, everything is as expected, but when checking against hex or elf: If you specify address it is treated as an offset from beginning of RAM... So sometimes OpenOCD starts the check in completely wrong location... 4\/3!! Hi Freddie, Thank you so much for your speedy reply! Indeed, this confirms my suspicions. I gather from your input, that if I switch to verifying using .bin format, based on the .text sections of the ELF file, then this might be an adequate workaround. A quick test I did was able to successfully verify the .bin format. Do I need to forward this problem description to some other mailing list / issue tracking system in order for it to be taken into consideration for future releases? Again, thanks heaps for helping me out in this issue! Best regards, // MS ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem with OpenOCD 0.5.0-rc1 and STM32 verify_image
On Thu, Jul 21, 2011 at 10:44 PM, Magnus S. mankk...@yahoo.se wrote: Freddie Chopin freddie_chopin@... writes: I can partially confirm... Tested with 0.5.0-rc1 Comparing with right image works fine: Comparing with almost right image (compilation date inside has changed) works fine too: However... when checking against something completely wrong (almost completely different code) strange things happen. When checking against bin, everything is as expected, but when checking against hex or elf: If you specify address it is treated as an offset from beginning of RAM... So sometimes OpenOCD starts the check in completely wrong location... 4\/3!! Hi Freddie, Thank you so much for your speedy reply! Indeed, this confirms my suspicions. I gather from your input, that if I switch to verifying using .bin format, based on the .text sections of the ELF file, then this might be an adequate workaround. A quick test I did was able to successfully verify the .bin format. Do I need to forward this problem description to some other mailing list / issue tracking system in order for it to be taken into consideration for future releases? Again, thanks heaps for helping me out in this issue! Best regards, Looking at your log (first one, you shouldn't specify an offset when using elf so the errors in the 2nd are expected) I don't think it's obvious that there's a bug. Rather it seems that you have a section in your elf file located at 0x2000 (ram) and openocd dutifully attempts to compare it and naturally fails. The first section, placed at 0x0800 checksums OK and it doesn't fail until the ram section is checksummed. Can you examine your elf-file and see if and why there is section in ram? Linker script bug? However I can't explain Freddie's reproduced failures. Maybe post the hex files (matching, slightly different and very different) and I can see if I can take a closer look at it? /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
