Release candidate for mbed-os-5.5.0-rc3 #4568
Conversation
Remove HAL_Init and related code from SystemInit and move it to mbed_sdk_init. The function SystemInit is called early in the boot sequence before RAM is initialized or the VTOR is setup, so it should not be used to perform the HAL initialization. This fixes crashes due the vector table being used before it has been relocated.
This fixes an issue as Timer.h is mbed file, thus if this file gets included first, causes failures.
cmsis 5 does not include it but as mbed 2 requires this, we will bring this file back. This brings back few other dependencies, that we add only for cortex-a. Once cortex-a gets cmsis5 and rtx2 support it will be updated.
|
/morph mbed2-release |
|
/morph export-build |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
|
deepikabhavnani
requested review from
jeromecoutant
and removed request for
jeromecoutant
Result: SUCCESSYour command has finished executing! Here's what you wrote!
Outputmbed Build Number: 66 All exports and builds passed! |
|
/morph test-nightly |
Result: FAILUREYour command has finished executing! Here's what you wrote!
OutputTest failed! |
|
/morph test-nightly |
Result: FAILUREYour command has finished executing! Here's what you wrote!
OutputTest failed! |
|
/morph test-nightly |
|
So we figured out what happened. It's kinda interesting. In Austin we have a /22 network. That is, our netmask is 255.255.252.0. If you're familiar with IPv4, this will tell you that IP addresses with the lower 10 bits set (such as 10.118.15.255) are broadcast addresses. Now in this case, the device was being given the IP address 10.118.13.255, which looks like a broadcast address, but it's off by one bit. Sure enough, this IP address prevented the device from resolving DNS queries. And since DHCP leases are cached by MAC address, the same board would usually get the same IP address, adding to the confusion. In trying to debug the issue, I set up a NATed /22 network to log the network traffic, but strangely enough the device worked perfectly fine with the 10.118.13.255 address. Weird. So I set up my laptop to use the 10.118.13.255 on the Austin network, and sure enough Windows was unable to resolve DNS queries either. So we're pretty sure this is an IT issue at the moment and we've forwarded the issue. We have a device running locally that's just sitting on the 10.118.13.255 address in the meantime, so we should be able to continue testing. |
Result: FAILUREYour command has finished executing! Here's what you wrote!
OutputTest failed! |
|
/morph test-nightly |
Result: FAILUREYour command has finished executing! Here's what you wrote!
OutputTest failed! |
|
/morph test-nightly |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
OutputAll builds and test passed! |
|
LGTM ! |
No description provided.