These calls were all moved into `main.c`, however this call was not
removed from litex. As a result, litex was calling `board_init()` twice.
This is currently not a problem, as `fomu` is able to be initialized
twice without issue, however future boards may have issue with this.
This fixes#2991.
Signed-off-by: Sean Cross <sean@xobs.io>
From the change:
// xtensa has more registers than an instruction can address. The 16 that
// can be addressed are called the "window". When a function is called or
// returns the window rotates. This allows for more efficient function calls
// because ram doesn't need to be used. It's only used if the window wraps
// around onto itself. At that point values are "spilled" to empty spots in
// the stack that were set aside. When the window rotates back around (on
// function return), the values are restored into the register from ram.
// So, in order to read the values in the stack scan we must make sure all
// of the register values we care about have been spilled to RAM. Luckily,
// there is a HAL call to do it. There is a bit of a race condition here
// because the register value could change after it's been restored but that
// is unlikely to happen with a heap pointer while we do a GC.
Fixes#2907
* Fix flash writes that don't end on a sector boundary. Fixes#2944
* Fix enum incompatibility with IDF.
* Fix printf output so it goes out debug UART.
* Increase stack size to 8k.
* Fix sleep of less than a tick so it doesn't crash.
This pulls all common functionality into `shared-bindings` and keeps
platform-specific code inside `nrf`. Additionally, this performs most
validation in the `shared-bindings` site.
The only validation that occurs inside platform-specific `common-hal`
code is related to timeout limits that are platform-specific.
Additionally, all documentation is now inside the `shared-bindings`
directory.
Signed-off-by: Sean Cross <sean@xobs.io>
The previous setting of `1` meant that the bluetooth system couldn't be
used when the watchdog timer was enabled.
Signed-off-by: Sean Cross <sean@xobs.io>
As part of the reset process, save the current tick count to an
uninitialized memory location. That way, the current tick value will be
preserved across reboots.
A reboot will cause us to lose a certain number of ticks, depending on
how long a reboot takes, however if reboots are infrequent then this
will not be a large amount of time lost.
Signed-off-by: Sean Cross <sean@xobs.io>
For `microcontroller.reset()`, don't manually call NVIC_SystemReset().
Instead, call the `port_reset()` in case the port wants to do any
cleanup.
Signed-off-by: Sean Cross <sean@xobs.io>
