1 Topic by jrandombob (edited by jrandombob 2016-08-02 19:00:05)

  • Registered: 2016-08-02
  • Posts: 2

Topic: STM32 woes

Hi All,

             I've been digging around for a crypto library (more specifically implementations of MD5 and AES-128) which will play nicely with the STM32F0 series with a minimum of fuss.

WolfSSL is the fourth option I've tried, and thus far the most promising, however I've run across an odd issue.

The call to XMEMCPY on line 321 of md5.c is causing my target to HardFault, the oddity is when I come to debug it;

If I disassemble the pre-objconv ELF file in IDA I see the following;

.text:08002640                 CODE16
.text:08002640
.text:08002640 ; =============== S U B R O U T I N E =======================================
.text:08002640
.text:08002640 ; Attributes: thunk
.text:08002640
.text:08002640 __memcpy_from_thumb                     ; CODE XREF: wc_Md5Update+3Cp
.text:08002640                                         ; wc_Md5Final+ACp ...
.text:08002640                 BX      PC
.text:08002640 ; ---------------------------------------------------------------------------
.text:08002642                 ALIGN 4
.text:08002644                 CODE32
.text:08002644
.text:08002644 loc_8002644                             ; CODE XREF: __memcpy_from_thumbj
.text:08002644                 B       memcpy
.text:08002644 ; End of function __memcpy_from_thumb
.text:08002644

Which is all good and happy, if I follow the branch to memcpy I end up in something that looks very much like a memcpy function.

If however, I run it up on the target and step through in GDB, I see the following;

0x8002640 <__memcpy_from_thumb>    bx     pc 
0x8002642 <__memcpy_from_thumb+2>  nop        ; (mov r8, r8)
0x8002644 <__memcpy_from_thumb+4>             ; <UNDEFINED> instruction: 0xff81eaff

I gather the "ALIGN 4" "metainstruction" maps to the NOP above, but I'm not sure what's going on at 0x08002644, which should be the "B memcpy" instruction.

Also FWIW the disassembly of __memset_from_thumb which follows is similarly afflicted.

Some weird alignment issue maybe?

I've no idea where to go as far as troubleshooting this issue... Any suggestions would be greatly appreciated.

Thanks,

-J

Share

  • Registered: 2016-08-02
  • Posts: 2

Re: STM32 woes

Looks like it's not specific to WolfSSL, dropped it out and wrote some user code calling memcpy and ended up with the same issue, still if anybody has any idea I'd be interested to see your suggestions

Share

  • Registered: 2015-10-07
  • Posts: 432

Re: STM32 woes

Hey Jrandombob,

Its possible the compiler/libc you are using requires an aligned pointer, but that is not typical. A memcpy function is super simple and can sometimes be optimized for 32-bit CPU's to copy int by int, vs. byte by byte.

Which compiler and libc are you using? What are your hard fault registers values telling you? https://community.arm.com/thread/5414

If this memory you are writing to comes from an alloc have you verified its a valid, usable address? Is it just memcpy or is it affecting other libc functions?

David

Share