Topic: Hardfault with Atmel Client / Server TLS example

Hello all,

I was hoping to evaluatie WolfSSL + ATECC508, so I went ahead and purchased the hardware listed as requirements in  https://www.wolfssl.com/wolfSSL/wolfssl-atmel.html in an attempt to test the first example (client/server). After building the associated projects and flashing the devices I see the client open a socket with the server before both devices hardfault. As far as I can tell, there appears to be an uninitialized memory access causing this fault. I see the following output:

-- TLS SERVER starts with ATECC508A over WINC module --
(APP)(INFO)Chip ID 1503a0
(APP)(INFO)Firmware ver   : 19.3.0
(APP)(INFO)Min driver ver : 19.3.0
(APP)(INFO)Curr driver ver: 19.3.0
M2M_WIFI_RESP_CON_STATE_CHANGED: CONNECTED
M2M_WIFI_REQ_DHCP_CONF: IP is 10.1.4.119
WINC is connected to TempE successfully!
Socket Event : BIND socket event
socket callback : bind success!
Socket Event : LISTEN socket event
socket callback : listen success!
Socket Event : ACCEPT socket event
socket callback : accept success!


Hard fault handler (all numbers in hex):
R0 = 0
R1 = f
R2 = 2deb5
R3 = 2ded3
R12 = ca62c1d6
LR [R14] = 22aa7  subroutine call return address
PC [R15] = 2135a  program counter
PSR = 1000000
CFSR = 0
HFSR = 0
DFSR = 0
AFSR = 0
MMAR = 0
BFAR = 0

Is there modifications or perhaps a missing build step that I am missing? Alternatively is there a specific version of atmel studio that is recommended for evaluating this demo? Another post (https://www.wolfssl.com/forums/topic965 … c508a.html) mentioned this port may not be completely finished. I did however see example output in the Readme that leads me to believe I have made a mistake somewhere along the line.

If anyone has had success with this example I would really appreciate the help getting past this point.

Thanks,

-Nathan

Share

Re: Hardfault with Atmel Client / Server TLS example

Hi Nathan,

I assume you have downloaded the Atmel demo `Atmel_ATECC508_Demos.zip` from the web page and are using Atmel Studio to build and debug. Are you using the SAMD21 or some other board?

Would you mind enabling our logging and sending the log output? Add the define `#define DEBUG_WOLFSSL` and call to `wolfSSL_Debugging_ON()` somewhere early in the boot process, like before wolfSSL_init().

A common reason for a fault like that is not setting the stack size high enough.

I created our ATECC508A demo and have the hardware to try and reproduce any issues, so we should be able to resolve this quickly.

Thanks,
David Garske, wolfSSL

Share

Re: Hardfault with Atmel Client / Server TLS example

Hi David,

Thanks for the quick responce!

For starters I downloaded Atmel_ATECC508_Demos.zip and am debugging/building for the samd21 with Atmel Studio 7. My hardware setup is as follows:

  • SAMD21XPLAINED PRO

  • WINC1500 XPRO

  • CRYPTOAUTH XPRO

I defined DEBUG_WOLFSSL in user_settings.h and called wolfSSL_Debugging_ON() at the very beginning of both tls_start_server and tls_start_client. Unfortunately the resulting log outputs were identical. You mentioned the importance of placing this function before wolfSSL_init() and i'm starting to think that might be related to the hardfault.

I spent some time debugging the project and found that breakpoints set in wolfSSL_init() never triggered before the hardfault. The hardfault address evaluated to atGetExecTime() at the evaluation of cacmd->execution_times[cmd]. I set breakpoint and found that the first call to this function is evaluating a NULL ATCACommand, resulting in the hardfault. This is the (formated) call stack at that moment:

>    client.elf! atGetExecTime()              atca_command.c:630    
     client.elf! atcab_read_zone()            atca_basic.c:1100    
     client.elf! atcacert_read_cert()         atcacert_client.c:87    
     client.elf! tls_build_signer_ca_cert()   tls_common.c:578    
     client.elf! tls_start_client()           tls_client.c:411    
     client.elf! main() Line: 193                

It seems that the function is passed _gCommandObj which has yet to be initialized to a valid pointer. This seems to occurs in atcab_init() or atcab_init_device(). As far as I can tell neither of these functions are called until later in tls_start_*, within tls_load_wolfssl_objects(), which calls wolfSSL_Init().

Hopefully this debug info is helpful. It seems like I'm missing something, but after debugging for a while I still can't figure out what. If you have any other suggestions let me know.

Share