search

microbit-foundation / standalone-error-program

A small, standalone (No CODAL) bit of code to display errors on the micro:bit, for use in DAPLink and as a template for BLE bootloader
MIT License
0 stars 1 forks source link

Display update issues with nrfx v2.3.0 #16

Open microbit-carlos opened 2 years ago

microbit-carlos commented 2 years ago

Edit: I first though the issue was introduced in v2.4.0, but it was in 2.3.0. The text below has been updated to reflect this.

Updating nrfx to version 2.3.0 (currently at v2.0.0) makes the display flicker, similarly to the strobe effect you get sometimes when recording the micro:bit display with a camera.

Going back to version 2.2.0 and it works fine again. ~The changes in the nrfx repo are all added as a single commit, so it's not really possible to do a git bisect to easily capture an smaller commit that introduces the change~. The main bulk of the changes bewteen 2.2.0 and 2.3.0 are in a single commit, so unless we get lucky with a bisect it'll be on the main commit:

From the changelog: 

## [2.3.0] - 2020-08-19
### Added
- Added support for nRF52805.
- Implemented workaround for nRF52 Series anomaly 197 in the POWER HAL.
- Implemented workaround for nRF52 Series anomalies 211 and 223 in the USBD driver.
- Added support for the nRF53 Series in the QSPI HAL.
- Added function in the GPIO HAL that returns port index.
- Introduced a QSPI HAL symbol that indicates the availability of the QSPI mode 1.
- Introduced shortcut functionality in the CCM HAL.
- Added function in the TIMER HAL for setting the specified shortcuts.
- Added optional two-stage start procedure of the LFXO in the CLOCK driver.

### Changed
- Updated MDK to 8.35.0.
- Divided network and application core-specific functionalities for nRF5340 in the RESET HAL and the reset reason helper.

### Fixed
- Corrected assertions in the NVMC driver.
- Corrected return types in the CCM HAL.
- Fixed setting of program memory access mode for secure code in the NVMC driver.
- Removed usage of the NRF_UICR symbol on non-secure targets in address validity checks in the NVMC driver.
- Fixed an error message in the SPIM driver that prevented successful compilation with logging enabled.
- Fixed unused parameters in the PPI HAL.

Not something we need to worry about at the moment, as there isn't a reason to update, but worth keeping in mind in the future.

microbit-carlos commented 2 years ago

Reducing microbit_sapanic_ROWDELAY from 20_000 to 5_000 (1/4) and microbit_sapanic_CHARDELAY from 1_000_000 to 500_000 (1/2) makes the screen update rate to be fairly close.

The new nrfx and new values end up a bit quicker than the old version, but that seems to be the main difference.

Maybe something about the default clocks could have changed?

finneyj commented 2 years ago

Get Outlook for Androidhttps://aka.ms/ghei36

From: Carlos Pereira Atencio @.> Sent: Friday, September 3, 2021 5:12:17 PM To: microbit-foundation/standalone-error-program @.> Cc: Subscribed @.***> Subject: [External] [microbit-foundation/standalone-error-program] Display update issues with nrfx v2.4.0 (#16)

This email originated outside the University. Check before clicking links or attachments.

Updating nrfx to version 2.4.0 (currently at v2.0.0) makes the display flicker, similarly to the strobe effect you get sometimes when recording the micro:bit display with a camera.

Going back to version 2.3.0 and it works fine again. The changes in the nrfx repo are all added as a single commit, so it's not really possible to do a git bisect to easily capture an smaller commit that introduces the change:

From the changelog:

[2.4.0] - 2020-11-13

Added

Changed

Fixed

Not something we need to worry about at the moment, as there isn't a reason to update, but worth keeping in mind in the future.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrobit-foundation%2Fstandalone-error-program%2Fissues%2F16&data=04%7C01%7Cfinneyj%40live.lancs.ac.uk%7C8997f9d5124c4ffda04108d96ef59bf8%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C0%7C637662823442962851%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NDFre2Uigd5UtrTqFeLbC09a81b%2F%2FN8e8XCjQrPhIeQ%3D&reserved=0, or unsubscribehttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACYBI3YJWT4LWM5K37EU7QDUADXWDANCNFSM5DMB2CFA&data=04%7C01%7Cfinneyj%40live.lancs.ac.uk%7C8997f9d5124c4ffda04108d96ef59bf8%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C0%7C637662823442972803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2Ff%2BXl2CsIZ64XRqX%2F4qjQeXWobBjtugiS29V144JdrI%3D&reserved=0. Triage notifications on the go with GitHub Mobile for iOShttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04%7C01%7Cfinneyj%40live.lancs.ac.uk%7C8997f9d5124c4ffda04108d96ef59bf8%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C0%7C637662823442972803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OzlgRM4%2FbvnPb%2F2jofCcgWSAAUNROpDjWUq1Nz1cO2c%3D&reserved=0 or Androidhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04%7C01%7Cfinneyj%40live.lancs.ac.uk%7C8997f9d5124c4ffda04108d96ef59bf8%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C0%7C637662823442982760%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cZco9FvTbJXjVbiPPMvjrZAWZuZdu1rjW8VTFcSXgU8%3D&reserved=0.

martinwork commented 2 years ago

Timing simply uses those DELAYs in a loop reading nrf_gpio_pin_out_read, so does that mean nrf_gpio_pin_out_read is running up to 4 times slower?

https://github.com/microbit-foundation/standalone-error-program/blob/master/MicroBitSAPanic.c#L190

microbit-carlos commented 2 years ago

@finneyj thanks for the response, but I think we go an empty email. Also I've updated the original comment, turned out that the issue was introduced in v2.3.0, so I've updated the changelog copy/paste for that version.

@martinwork Yeah, if the busy loop is doing some GPIO stuff then either the GPIO code is slower (maybe more code executed in nrf_gpio_pin_out_read()?) or the clocks are configured to run slower?

From the changelog I was wondering if it could be related to this, but it's technically it should only affect the low frequency oscillator:

Added optional two-stage start procedure of the LFXO in the CLOCK driver.