Open microbit-carlos opened 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?
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:
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.
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
@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.
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:
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.