flash/fds hardfault not traceable

RE: flash/fds hardfault not traceable

Juliusc — Thu, 14 Apr 2022 09:15:24 GMT

bit disappointed with this issue, but will close it now since I don't get an answer.

RE: flash/fds hardfault not traceable

Juliusc — Wed, 13 Apr 2022 12:18:40 GMT

I might have a clue, could need some confirmation and maybe help on that. After enabling the flash module I later use rtc_enable() in one of my modules. removing this module seems to not carry a hardfault any more but I cant really let that go. So what might be up here?

RE: flash/fds hardfault not traceable

Juliusc — Wed, 13 Apr 2022 12:18:40 GMT

RE: flash/fds hardfault not traceable

Juliusc — Wed, 13 Apr 2022 09:53:27 GMT

another question: is there maybe a way to write to flash without IRQs? would rarely write there so I could also poll it at runtime

RE: flash/fds hardfault not traceable

Juliusc — Wed, 13 Apr 2022 09:28:39 GMT

what do you think about priorities? Do I need to change smth here and what exactly?

RE: flash/fds hardfault not traceable

Juliusc — Wed, 13 Apr 2022 08:15:00 GMT

I need to bother you with this again.

I also tried using the storage example, it throws a hardfault at the same function (event_write) and since I thought this example doesn't use the softdevice I suppose there is something else wrong. I ran the example on my custom PCB -- this works. How could I find out if my flash segments are wrong? and how can I see if I take too much space on the flash? I need this to work and yeah I got some custom stuff in my project but there must be a way to find out what Im doing wrong.

RE: flash/fds hardfault not traceable

Juliusc — Mon, 21 Feb 2022 13:53:57 GMT

yeah, I suppose most include directories are in my solution options not the ones for the project (i.e. they are inherited)

I will try to do it this way round, although its clear that by this I might just run into different problems.

What I wanted to know is if you know how the attachment of the fds_evt_handler works exactly. THats where my application seems to crash, it doesn't go into the handler in the event_send function.

RE: flash/fds hardfault not traceable

Edvin — Mon, 21 Feb 2022 11:45:10 GMT

Hello Julius,

I have looked into it from time to time, but I can't figure out why it doesn't work.

I have tried to look for differences in your project settings and sdk_config.h, but so far with no luck.

I see that the project configurations in your project are quite different from what it is in our examples. Perhaps you have done everything yourself? Or did you start with an example from the SDK?

One example of weird behaving settings is that your include directories shows up like this:

But it actually include many more folders. Since this is a bit off, then perhaps there are plenty of other settings not showing correctly as well, for all I know.

I also tested by adding your flash_tb_radar.c/h into the flash_fds example, and there it runs without any issues. (attached in case you want to test).

devzone.nordicsemi.com/.../flash_5F00_fds_5F00_test_5F00_cust.zip

Do you happen to know why the include directories setting looks like that? Does it do that in your case as well?

Is there an option to go with the attached sample, and add the rest of your project to that?

BR,
Edvin

RE: flash/fds hardfault not traceable

Juliusc — Wed, 16 Feb 2022 14:54:41 GMT

Hi Edvin,

I still havent figured this out (I didn't focus so much on it but want to get it done asap)

Did you find out anything? how does the flash placement look? heap and stack sizes shouldn't interfere here I suppose?

Best, Julius

RE: flash/fds hardfault not traceable

Juliusc — Tue, 08 Feb 2022 11:41:42 GMT

Thanks for the answer!!

I tried the same btw. FYI, I also used my sdk_config h file on the example and this didn't yield the behavior

RE: flash/fds hardfault not traceable

Edvin — Mon, 07 Feb 2022 20:43:45 GMT

Hello,

Yes, I was able to look into this on friday, and after modifying the project a bit, (from using printf to NRF_LOG_...(), changing a lot of the absolute paths for your .c files and include folders, are the two main things I remember now), I was able to reproduce the issue. It looks like the FDS is struggling to initialize the flash pages, although I didn't understand why. It requires some more debugging. I am sorry I didn't get back to you today, but I have not forgotten this ticket. I need to look deeper into it.

I saw that a lot of your project settings vary quite a bit from the normal SDK examples. I am not sure whether this is related to the behavior. And again, I am sorry I don't have a definitive answer for you at this point in time. I will try to look closer into this tomorrow.

I have, however, tried the unmodified flash_fds example, which doesn't behave the same as your project. I think my approach will be to copy your files into the flash_fds example, and see how it behaves then, to try a different approach, and to eliminate that the project settings may be the issue. Just in case you want to try to debug this as well.

Best regards,

Edvin

RE: flash/fds hardfault not traceable

Juliusc — Mon, 07 Feb 2022 13:55:15 GMT

Hi Edvin,

were you already able to check this?

Greetings

RE: flash/fds hardfault not traceable

Juliusc — Thu, 03 Feb 2022 13:13:58 GMT

devzone.nordicsemi.com/.../flash_5F00_corrupt_5F00_ex.ziphere you go. I literally deleted everything from my main and excluded all of my files except the flash_init part (I also commented out ble_stack_init() in there)

I am using 15.3 rn

Thank you Edvin

RE: flash/fds hardfault not traceable

Edvin — Thu, 03 Feb 2022 12:50:30 GMT

If you are able to reproduce this on a DK now, perhaps you can zip your project and upload it here? You can exclude any potential sensitive information. If the project is a strip down, containing only the bare minimum required to reproduce the issue, without too much of your custom code, that would be the best. Then I can try to reproduce it here in the office.

What SDK version are you using?

Best regards,

Edvin

RE: flash/fds hardfault not traceable

Juliusc — Thu, 03 Feb 2022 08:39:22 GMT

Its not like I didnt, as I said, there is no other outcome than what I have right now. The event_send is also triggered if I somewhat alter the code and leave out other snippets.

its an sd_event_IRQHandler that is triggered all of the sudden and probably interfering with anything .

event_send is one of nordics functions in nrf_storage_sd.c triggered by fstorage_sys_evt_handler and at the beginning its sd_event_IRQHandler

Also, I tried this again on my DK and it happened there too now.

When I only init the flash and don't do anything else, it wont crash, as soon as I use fds_stat or any other action on flash write/read it will show this error.

RE: flash/fds hardfault not traceable

Edvin — Wed, 02 Feb 2022 14:49:16 GMT

Do you use FreeRTOS? Does your application currently use the softdevice? I.e. do you enable the BLE stack from your application?

Either way, I think you need to start debugging. Use breakpoints to see how far your application gets before it hardfaults. If you use the softdevice, you need to set breakpoints, wait for it to hit, and then move the breakpoint and reset the application.

Start checking around the event_send(). Try to set a breakpoint and see where it is coming from, and what it tries to do. What file is this function implemented in?

Best regards,

Edvin

RE: flash/fds hardfault not traceable

Juliusc — Wed, 02 Feb 2022 14:36:07 GMT

I am using a LFXTAL and erased all software as well.

yeah Im curious whats going on as well. I also used the example on my custom PCB and that works ok. So there must be some weird interaction between board, flash and whatever else in the configuration (I also commented out all of the other modules and the hardfault still occurred)

fds was indeed the last thing I added and the device works fine without.

RE: flash/fds hardfault not traceable

Edvin — Wed, 02 Feb 2022 14:33:19 GMT

So if you flash the same application to a DK without changing anything the issue doesn't occur? Have you tried erasing both boards completely before flashing the application? (nrfjprog --eraseall)

Apart from that I can't think of anything that would cause a hardfault. One typical thing that causes different behavior is the lack of LFXTAL in some custom boards, but that would typically cause a stall, not a hardfault. Does your custom PCB have an LFXTAL (low frequency xtal?).

Was the FDS the last thing you added? If you comment out your initialization of FDS/fstorage, does the device hardfault?

Best regards,
Edvin

RE: flash/fds hardfault not traceable

Juliusc — Wed, 02 Feb 2022 13:46:10 GMT

I am actually not writing anything. Basically I just initialize the flash module and afterwards dont use it (at least for now)

the fault just happens randomly (an interrupt that is triggered?). Thats why I added the picture, this is all I have, if I set a breakpoint it will lead to the same call stack.

Yes it happens the first time the firmware goes into this event_send method.

Using a DK was a good advice, I couldn't recreate te problem there, is it something in the board configuration that needs to be handled?

RE: flash/fds hardfault not traceable

Edvin — Wed, 02 Feb 2022 13:37:06 GMT

Hello,

It is a bit difficult to say exactly why this is not working. What address are you trying to write to? Or perhaps there is an event handler that isn't populated properly being called? Is it possible to recreate the issue on a DK? If so, would it be possible to send the project that replicates this so that I can have a look?

If not, I suggest you start looking into the call stack. What happens at event_send() right before the hardfault? Have you tried setting a breakpoint? Does it happen the first time this function (event_send()) is called, or is it called a couple of times before the error occurs?

Best regards,

Edvin