Changed HAL_MspInit to mbed_main #6023
Conversation
|
User not whitelisted, CI not run. |
| * in user defined file as described in documentation | ||
| */ | ||
|
|
||
| void HAL_MspInit(void) | ||
| void mbed_main(void) |
There was a problem hiding this comment.
This is mbed_main: User's code to be executed before main(). . Should not be defined in the targets
What problem is here? Why a target code needs kernel to be initialized ?
There was a problem hiding this comment.
See #5995: our C030 board requires configuration of a voltage level in its battery charger chip if it is to work reliably. This battery charger chip is only configurable over I2C. The [standard ST] I2C drivers make calls to wait_us(), which is an RTOS function. So our target code needs to do this configuration call after the RTOS has been initialised and before entry to main(). Is there such a hook, other than mbed_main()?
There was a problem hiding this comment.
Is there such a hook, other than mbed_main()?
No, there is not.
target code should use what it has, target code, in this case us ticker functionality.
There was a problem hiding this comment.
So I guess it is a rule that target code should not use RTOS calls. Is that written down somewhere, just so that I can have the discussion with ST (whose code it is)?
There was a problem hiding this comment.
Grepping around a little, there are calls to wait_ms() and wait_us() all over the place in the target code so I don't see how it can be a rule that target code should not use RTOS calls. The other option would be to introduce a hook for target configuration to occur after the RTOS has been initialised, since I can see that being generally useful. I will raise a separate issue for this.
|
This change is not required. Instead please refer to #6034. |
Description
Bug fix for C030 battery charger. There is a wait function being called in the boot process (inside HAL_MspInit) and at that stage, the kernel has not been initialised. A fix for this would be to use mbed_main() instead of HAL_MspInit() in user file as mbed_main() is being called at a later stage in the boot process.
@RobMeades is already following up this issue, please refer to #5995