Hard fault when debugging TLS because pointer was zeroed. - but is it a bug?

[EdGo_4771641]

I used the snip tcp_client to make a basic tcp client, and that worked without a problem. I also had no problem debugging it.

I then added TLS, with a certificate in the DCT.

However, now I'm getting hard faults. I think it's because it's calling a function from a structure pointer that gets a zero value. When i step up to the line that pointer gets zeroed, it looks like it should be zeroing something else, but it zeroes the wrong memory. The below screenshots represent the before and after a memset. it looks to be zeroing the wrong memory, but can't be sure:

when you step over the memset, the cursor also skips.

THis step might not cause the hard fault, but this happens in other places too.

Any help would be appreciated. Thanks.

[Zhengbao_Zhang]

Hello:

    Which version are you using now for the test ? I see we solved some TLS issues along with the version update.

and if you didn't add WICED_DISABLE_TLS in test, some memo should already have the TLS flow..

[EdGo_4771641]

Hi Zhengbao,

I am using Wiced_006.006.000.0009 – although when I downloaded the IDE again, some WICED platform files had been updated, although the version file had not changed. I can see that this is because the MurataType1LD platform zip file has changes to driver files like spi_flash.

WICED_DISABLE_TLS is not added

I can't tell if it's stack/memory corruption, or if it's a problem with the certificate I'm using. I don't think it's a big or complicated certificate.

How would I know if I need to expand heap or stack allocations, or do anything special?

Thanks in advance,

Ed.

[Zhengbao_Zhang]

Hello:

I then added TLS, with a certificate in the DCT.

I get some examples from our snip code..  seems we often read out cer from file in resource system not in DCT.

You can get the code example from Secure_matt.c

Then we can see if the Hard fault still exists.

void application_start( void )

{

    static wiced_mqtt_object_t mqtt_object;

    wiced_result_t ret = WICED_SUCCESS;

    uint32_t size_out;

    wiced_init( );

    /* Read root CA certificate (self certified) from resources*/

    resource_get_readonly_buffer( &resources_apps_DIR_secure_mqtt_DIR_secure_mqtt_root_cacert_cer, 0, MQTT_MAX_RESOURCE_SIZE, &size_out, (const void **) &security.ca_cert );

    security.ca_cert_len = size_out;

[EdGo_4771641]

Hi Zhengbao,

I tried using resources instead of DCT, but it fails in the same way.

In any case, the tutorial showed it's ok to use the DCT: https://www.cypress.com/brightcove/colorbox/1694399810001/5715403789001/Bkkie0EFg/WICED%20Wi-Fi%20101%3A%20Lesson%206-7%20Complete%20Secure%20Connection?height=490px

I would be happy to send you the code, I would just have to set up a temporary certificate and server.

The behaviour is different if I don't use the correct certificate for the server. – it fails elsewhere with a proper WPRINT_SECURITY_ERROR error. So that means that the certificate is definitely correct for the port.

Kind regards,

Ed.

[Zhengbao_Zhang]

Hello:

  yes, please send me your code, I can have a  try in my side, but I am busy in an onsite support these days, It will have a delay before my verification.

[EdGo_4771641 · Accepted solution]

In the end, I have found the problem. It wasn't stack corruption or overflow. I had initialised the tls_context with a local variable which then didn't exist in the thread that came to use it.

i.e. the tls_context was a local variable. it should have been with the same scope as tcp_client_socket (global) so it would have always been available at the same time.

    result = wiced_tls_init_context( &tls_context, NULL , NULL );

    result = wiced_tcp_enable_tls( &tcp_client_socket, &tls_context );

It wasn't a problem with the stack, so I didn't need to change NETWORKING_WORKER_THREAD_STACK_SIZE

[Zhengbao_Zhang]

great and congratulations, thanks a lot for your share.