Closed AlessandroA closed 8 years ago
I would like to find out the real cause of this, if we can fix it in our code base or not. Is this critical , as to be fixed within today or can wait until Monday to have a quick look at stdio initialization ?
I am happy with fixing this until we get real cause. If this gets in, a tracking issue would be good to have.
This is a workaround that unblocks uvisor-helloworld.
If OOB testing starts on Monday I'd like this to be merged, as uvisor-helloworld cannot work otherwise. We can create an issue and track this here in core-util, to remind us to revert the changes when we fix the real problem.
If OOB testing starts on Monday I'd like this to be merged, as uvisor-helloworld cannot work otherwise. We can create an issue and track this here in core-util, to remind us to revert the changes when we fix the real problem.
@bogdanm agree?
Yes, we have to do this for now. +1.
Please don't forget to open the tracking issue.
For the moment assertions need to be commented out as this code might run when the libc initialization has not completed yet. In those cases, an uninitialized stderr pointer will trigger a bus fault / uVisor access fault as it points to flash (
__sf_fake_stderr
).For reference: ARMmbed/mbed-drivers#176 Printing to stderr attempts a write into flash
@bogdanm @0xc0170 @adbridge