RTC1_IRQHandler(); Error

[jackiemoon98]

Hi all,

I am debugging a program after compiling with no errors using the SDK 15.2.0 on a windows laptop and nRF52840 board. The program was designed to save 8 bytes of data to flash every 50ms for 3 days using fstorage. There should be enough storage on this particular board to allow for this, however I have not had a successful 3 day run yet. The latest bug in the code occurred at "void RTC1_IRQHandler();" in the call stack and about 90 minutes in with an error value of what looks to be 0x00026FC4, which doesn't make sense, at least not to me. I understand this has something to do with the timers, which I use to call the fstorage functions every 50ms. However, as a beginner programmer, I am unable to assess any issues at a lower level. Could someone give some suggestions as to what may be causing this issue?

Thanks,

Jack

[jackiemoon98]

Hi Simon,

Yes the test ran for about 12 hours again. The segger IDE reported that there are 816.9 KB of flash free and 225.8 KB of RAM. The nRF Conect programmer read that there are 1024 KB of flash in pages of 4KB. I previously did not know the pages were 4KB and each test was only able to write this amount which suggests that it is an issue with writing to a new page. However, I ran another test in which I started saving to the address 0x46b00 so that the program would have to save on the next page, and it did so flawlessly. I also used nrf_end_address_get() which returned 1048567 (or 00100000 in Hex), proving plenty of room has been allocated for use in the flash_save_init(). 

Regarding the possibility of a timer, you are right, when I increased the saving frequency, the test only took around 2 hours. 

I am still working on using ACL and will leave a comment when I get results from that, however I figured you may be able to get further insight with this info in the meantime. 

Thanks again,

Jack 

[jackiemoon98]

Hi Simon,

I tried allowing read an write access to the flash memory using the ACL based off of the example in the link you shared. However, I included the below code after erasing the region I wanted to write to and the program would hard fault when  getting to the ACL part of the program. There was never a call stack or error code and I needed to reset the board in order to continue debugging. What am I doing wrong?

NRF_ACL->ACL[0].ADDR = 0x3f000;
NRF_ACL->ACL[0].SIZE = 24;
NRF_ACL->ACL[0].PERM = ACL_ACL_PERM_WRITE_Enable << ACL_ACL_PERM_WRITE_Pos;

Thanks,

Jack

[Simonr]

Hi Jack

I have consulted with one of the gurus here, and first, just stow away the ACL idea for now. Next, could you add DEBUG in preprocessor defines and enable logging. This way you should be able to find out which APP_ERROR_CHECK(err_code) is returning and what exact err_code it is. I'm not so sure it describes the flash page and error, it could be a multitude of things.

You should probably increase the saving frequency when testing by quite a bit, so you won't have to wait for hours each time.

Best regards,

Simon

[jackiemoon98]

Hi Simon,

I have been using logging this whole time and I am pretty sure I have been in debug mode.  However, I noticed that even with the debug flag on, debug was still turned off in the app_error_weak.c file. After looking into this, it appears to be a known issue with the sdk 15.2.0 in segger, but it is only visual. Unfortunately in my case, the program would still encounter NRF_BREAKPOINT_COND. After manually moving the lines from the #ifndef DEBUG to the break point, I am still running into inconsistent failures. Unlike before, the flash initialization is no longer working as it will always hard fault, as well as the adc function will get stuck in a loop. These bugs are even stranger as I never changed anything in the ADC timer, or anything other than the saving period in the fstorage timeout handler. Is it possible that there could be an issue with the hardware? I apologize for the off-topic errors, but I was unable to debug these issues and do not have any other resources to help....I hope these errors are all related. 

However, if I did in fact have logging and debug set up properly before, I would consistently get the 2006 error.  

Thanks again for your time,

Jack

[Simonr]

Hi Jack

It seems like you have been changing quite a few things within the files, and all these additional errors seems to be due to the changes made in the SDK files. This makes it almost impossible for us to find the error, and the project as a whole will get harder to work with. I suggest you go back to where you were. The point where you got consistent errors.

After you've done this, please ensure that you've set DEBUG in the preprocessor defines like this:

1. right click your project in SEGGER and click Options.
2. Make sure your configurations are set to Common.
3. Click the Preprocessor Definitions.
4. Enter DEBUG into the Preprocessor Definitions, and click OK until you are back to your project.

When this is done, use the unmodified error handler to check what error code you get when encountering the original error.

Best regards,

Simon