8000 nrf: nvm sd_flash_page_erase_sync() hangs · Issue #3296 · adafruit/circuitpython · GitHub
[go: up one dir, main page]

Skip to content

nrf: nvm sd_flash_page_erase_sync() hangs #3296

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

Clos 8000 ed
ricardoquesada opened this issue Aug 18, 2020 · 8 comments
Closed

nrf: nvm sd_flash_page_erase_sync() hangs #3296

ricardoquesada opened this issue Aug 18, 2020 · 8 comments

Comments

@ricardoquesada
Copy link

tested on:

  • CLUE
  • master branch. hash: 94ecf33

steps to repro:

Open REPL and then:

import _bleio
_bleio.adapter.erase_bonding()

It fails while trying to erase page address 0xea000 (page number 0xea).

circuitpython-6.0-alpha2 works Ok.
I compiled circuitpython following the instructructions from here: https://learn.adafruit.com/building-circuitpython/build-circuitpython using BOARD=clue_nrf52840_express

@ricardoquesada
Copy link
Author

in case it helps, I'm using gcc version: arm-none-eabi-gcc (GNU Arm Embedded Toolchain 9-2020-q2-update) 9.3.1 20200408 (release)

@tannewt tannewt added this to the 6.0.0 milestone Aug 18, 2020
@ricardoquesada
Copy link
Author

I did a bisect and the culprit commit is this one: d83a4ac

I tried with both with:

  • arm gcc 2020-q2-update (latest one)
  • arm gcc 2019-q4-major (recommended for circuit python 5 according the adafruit documnetation)

and with both I got the error. So, it seems to be a compiler error. But until it is fixed I'd remove the OPTIMIZATION_LEVEL = 2

@dhalbert
Copy link
Collaborator

Typically these errors are us forgetting to make something volatile or something is uninitialized. The error is hidden with less optimization. I'm not sure we've encountered an actual compiler bug. Thanks for the bisect. I'll try tracking down the issue.

@ricardoquesada
Copy link
Author

makes sense, thanks.

I debugged it a bit further, and:

  • there is a while (sd_flash_operation_status != SD_FLASH_OPERATION_IN_PROGRESS) {}... and code cannot exit this loop.
  • sd_flash_operation_status gets updated on SD_EVT_IRQHandler
  • but SD_EVT_IRQHandler is not being called after sd_flash_page_erase() is called. Not sure whether there is a race condition, or interrupts are masked

Might not be related to this bug, but seems to be safer to protect sd_flash_operation_status with an sd_mutex (?)

@dhalbert
Copy link
Collaborator

sd_flash_operation_status is volatile, so that's not the issue.

We had tended not to use sd_mutexs because there were a number of things that happened when the SD was not enabled, but this is not one of those.

@DavePutz
Copy link
Collaborator

Reproduced this on a Clue and other BLE functionality hangs as well. With the latest source BLE works as expected on a Circuitplayground Bluefruit. I commented out the spi and display initializations in ports/nrf/boards//clue_nrf52840_express/boards.c and then the Clue BLE works properly.
@dhalbert - do we possibly still have some memory conflict between BLE and displayio?

8000

tannewt added a commit that referenced this issue Sep 10, 2020
Correction for Issue #3296 - ble hanging on nrf52840
@ricardoquesada
Copy link
Author

should we close this since pr #3375 got merged?

@tannewt
Copy link
Member
tannewt commented Sep 24, 2020

Yup! Thanks @ricardoquesada

@tannewt tannewt closed this as completed Sep 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants
0