This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

RTC1_IRQHandler(); Error

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

Parents
  • Hi Jack

    Have you looked at the infocenter page for ACL, it should describe most ACL functions. Also this case has an example of implementing the ACL.

    Page 20 makes more sense to me as well when thinking about how long the application is running before crashing. Did it run for 12 or so hours this time as well? Do you know how much of the flash your application and SoftDevice uses, this is also a factor, as you won't have the entire 1MB free to write on. You can check this by reading your device with the programmer app in nRFConnect for desktop. 

    Also this could be a timer issue as you say, but that would cause it to crash at the same exact time after start every time, which I'm not sure it does.

    Best regards,

    Simon

Reply
  • Hi Jack

    Have you looked at the infocenter page for ACL, it should describe most ACL functions. Also this case has an example of implementing the ACL.

    Page 20 makes more sense to me as well when thinking about how long the application is running before crashing. Did it run for 12 or so hours this time as well? Do you know how much of the flash your application and SoftDevice uses, this is also a factor, as you won't have the entire 1MB free to write on. You can check this by reading your device with the programmer app in nRFConnect for desktop. 

    Also this could be a timer issue as you say, but that would cause it to crash at the same exact time after start every time, which I'm not sure it does.

    Best regards,

    Simon

Children
  • 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 

  • 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

Related