I have passed several hours trying to understand a bug at init that occurs with some boards, and not with others.
It was due to a hardware bug in early stm32f4, revision A one.
Marvellously, ChibiOS is aware of this problem, and defining STM32_USE_REVISION_A_FIX in mcuconf.h permit to fix it.
The question is : why not always doing that test instead of protecting him behind a somewhat hidden (or not so easy to find) macro definition ?
Alexandre
STM32_USE_REVISION_A_FIX
Moderator: RoccoMarco
Re: STM32_USE_REVISION_A_FIX
A very good question. Looking at the ChibiOS code, even when you enable this macro the I-Cache and D-Cache is only disabled for specific chipset revisions so it should have no effect on any that aren't broken. In other words, I can see no reason this isn't permanently enabled exactly as you suggest, to avoid the kind of grief you've had in tracking this down.
Giovani any insight into the thinking on this one?
Giovani any insight into the thinking on this one?
- Giovanni
- Site Admin
- Posts: 14893
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 997 times
Re: STM32_USE_REVISION_A_FIX
The main reason is that it is better being aware that there could be a performance difference in your system. This is why you need to explicitly enable that option if you know there could be A devices. Second reason is that A devices should not be that common anymore.
Giovanni
Giovanni
Re: STM32_USE_REVISION_A_FIX
I would say that such difficult to find problems are better solved-by-default.
The cost is "hours/days of debugging" versus a few bytes in flash and/or a performance impact in the case the bug is present.
The "switch" would be available for people running into flash size limitations to disable the check and save a few bytes. But the comment would say: If you are sure you don't have any rev-A devices you can disable this check.
For us mortals using chibios as a system, we like to have something up and running without having to know all the low-level details. That's why we use startup files that initialize the C runtime environment and a HAL to prevent having to mess with the registers.
The cost is "hours/days of debugging" versus a few bytes in flash and/or a performance impact in the case the bug is present.
The "switch" would be available for people running into flash size limitations to disable the check and save a few bytes. But the comment would say: If you are sure you don't have any rev-A devices you can disable this check.
For us mortals using chibios as a system, we like to have something up and running without having to know all the low-level details. That's why we use startup files that initialize the C runtime environment and a HAL to prevent having to mess with the registers.
Re: STM32_USE_REVISION_A_FIX
rew wrote:I would say that such difficult to find problems are better solved-by-default.
The cost is "hours/days of debugging" versus a few bytes in flash and/or a performance impact in the case the bug is present.
The "switch" would be available for people running into flash size limitations to disable the check and save a few bytes. But the comment would say: If you are sure you don't have any rev-A devices you can disable this check.
For us mortals using chibios as a system, we like to have something up and running without having to know all the low-level details. That's why we use startup files that initialize the C runtime environment and a HAL to prevent having to mess with the registers.
Fully agree. Good summary of why thanks.
- Giovanni
- Site Admin
- Posts: 14893
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 997 times
- Giovanni
- Site Admin
- Posts: 14893
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 997 times
Re: STM32_USE_REVISION_A_FIX
Hi,
The switch is now reversed in repository, you specify it in order to remove the fix.
Giovanni
The switch is now reversed in repository, you specify it in order to remove the fix.
Giovanni