I found the issue. >From the STM32F427 manual:
> Any attempt to read the Flash memory on STM32F4xx while it is being written or erased, > causes the bus to stall. Read operations are processed correctly once the program > operation has completed. This means that code or data fetches cannot be performed while > a write/erase operation is ongoing. So, although there isn't any critical section anywhere, the CPU halts as it cannot access the Flash memory. So the kernel tick timer is not able to be executed, and thus time-keeping is not possible. I may be able to use the read-while-write functionality of this MCU to overcome this. (I successfully demo'ed it, and it works correctly. But it may not be possible in the final application.) --- So at this point I would like to ask, how is the current time kept in this arch? Is it a hardware timer (that keeps running independently of the CPU)? Or is it a periodic IRQ that updates a "soft" timer? In the first case, I guess it is enough to trigger a "reschedule" after every progmem write. But in the second case, things are more complicated... Στις Τρί, 30 Νοε 2021 στις 2:00 μ.μ., ο/η Xiang Xiao < xiaoxiang781...@gmail.com> έγραψε: > On Tue, Nov 30, 2021 at 5:55 PM Fotis Panagiotopoulos <f.j.pa...@gmail.com > > > wrote: > > > Hello everyone, > > > > I have some issues with the watchdogs and possibly the scheduling of the > > kernel. > > > > I am not sure if this is a bug, or if I am miss-using something... > > > > I am working on an STM32F427, and I am using the independent watchdog > > timer. > > I have enabled the watchdog automonitor using a timer > > (WATCHDOG_AUTOMONITOR_BY_TIMER). > > Generally it works correctly. > > > > At one point in my application, there are some writes to the MCU Flash > > memory. > > There are multiple calls (5-6) to the write functions, so writing all > these > > data takes quite some time. > > > > During these writes, the hardware watchdog (IWDG) expires, and restarts > the > > system. > > As far as I can tell the kernel watchdog (timer) never fires. > > So, the auto-monitor stops working. > > > > This seems a bit odd to me, for two reasons: > > > > 1. I couldn't find anywhere in the progmem driver anything that disables > > interrupts. > > I think that the kernel should tick properly during the Flash writes. > > > > > Even though nobody disables interrupts, the OS may be stuck > sometimes(~10ms) because flash can't write and read at the same time. > > > > 2. Even if for some reason the kernel is locked during the write, I would > > expect a reschedule when the write finishes. > > As said, there are 5-6 calls, so between these calls shouldn't the kernel > > check for other tasks ready to run? > > > > Yes, the schedule should happen between each call. > > > > And of course check for any watchdogs ready to run and thus also run the > > auto-monitor? > > > > Do I understand anything wrong? > > > > In any case, what is the proper way to overcome this issue? > > > > > You can enable SCHED_CRITMONITOR related config to find why the kernel > stops the scheduling: > incubator-nuttx/Kconfig at master · apache/incubator-nuttx (github.com) > < > https://github.com/apache/incubator-nuttx/blob/master/sched/Kconfig#L707-L793 > > > > > > Thank you! > > >
