Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hard faulting on Giga R1 with display shield #69

Open
schnoberts1 opened this issue Nov 23, 2024 · 1 comment
Open

Hard faulting on Giga R1 with display shield #69

schnoberts1 opened this issue Nov 23, 2024 · 1 comment

Comments

@schnoberts1
Copy link

schnoberts1 commented Nov 23, 2024

Hi,

I have noticed on my Giga R1 Wifi with Display Shield that my system hard faults when left running. Sometimes it's just after boot and other times it takes many hours.

In tracking this down I have found that ECCX08 lib and/or hw maybe the cause. Assuming it gets past boot (which it will always do on a power cycle - so I think boot adjacent fails or to do with the I2C bus state being inconsistent on a soft reset) everything works fine until, at one point, the generate public key request fails. Once it fails it would seem that the next I2C request causes a hard fault. That maybe the next time the ECCX08 lib is called or maybe when another I2C device is accessed.

If you put a call to generate public key (or sign / verify) in a loop you should see the crash between 5 minutes and 5hrs (in my experience).

What puzzles me is why I get a hard fault. The code seems fine, and it returns with an error code. The hard fault has either no stack trace or a one line stack trace.

This happens on both the devices I have so it's not localised to a specific device.

I can space the calls out but I don't know if this is i) simply making the crash less likely or ii) a genuine workaround to a known (for someone more educated in these things than me) problem.

@schnoberts1
Copy link
Author

I noticed on arm that when the ECCX08 is built and run with -fsanitizer=undefined it complains about this line:

memcpy(&command[6], data, dataLength);

... as there are cases where dataLength are zero. I thought this was perfectly legal behaviour but the sanitizer is not happy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant