STM32WLE5JC: Add board configuration#129
Conversation
|
I'm guessing it's a combination of we never actually try to read/write past the end of flash and openocd generally handles the issue rather than causing errors. I think it is valid for tockloader to not try to write apps beyond the end of flash. I'm less sure about what should happen to writes and reads beyond flash; I think it's probably fine to handle those the same we do today and make it a board/openocd/user problem. Can we make this PR just the second commit, and work on the end of flash issue separately? I think if tockloader is to check that apps are going to far it needs to know where the end should be, and that should be set in tockloader.py. I'm happy to work on this. |
42d301b to
291f8e5
Compare
|
Sounds good, I just dropped the other commit. Looks like black is failing for some reason. I couldn't recreate this locally until updating black to 26.1.0. The failure is in It looks like Leon's PR also picked up this formatting issue but he checked in the |
So, I just squashed the formatting fixes into my commit, and I didn't realize those were also touching code that I didn't change. I'll merge this in with another PR and then we can both rebase. :) Edit: @tyler-potyondy if you rebase on |
This adds the stm32wle5jc chip used in the seeed_studio_lora-E5-HF dev board to tockloader's known board list. Communication intended to occur using stlink over openocd.
291f8e5 to
482ff75
Compare
|
Sorry for the delay circling back to this! Just rebased on master and CI is good now. |
|
Talking more with @ppannuto and @jmadden173 about this, it seems we should use the attribute table feature in the kernel for the app flash start. We have been optimizing the kernel size to fit on the somewhat small stm32wle5jc boards, which in turn has resulted in the app start changing and breaking this branch's tockloader functionality. All this is to say, let's block merging this until we update to pickup the attribute table. |
|
And what @tyler-potyondy ? |
|
Minor miscommunication in that comment / from my memory in the meeting earlier today before looking at code. The question was “why do we need this https://github.com/tock/tockloader/pull/129/changes#diff-4d77c2acd86ba2a9e6df5dd3155d1aa499b1c872312cbd5bea86b2ddb749aa8fR157” ( We could include something like We could just specify the board’s memory map as part of its config (i.e. start/end of flash [and maybe RAM too]) but that’s annoying to add for all the boards, and it really feels like there should be some way to get jlink/openocd/etc to just report that for an attached target [quick search confirms that’s in principle possible]; with that we could just dump all of flash and then scan for the kernel attribute table tl;dr—I think there’s better solutions, but updating I think we should just merge this as-is. FWIW, tockloader does read the kernel attributes already — indeed, it uses |
5 participants
Overview
This PR adds support for the STM32WLE5JC SoC (found on the Seeed Studio LoRa E5 dev board) via an STLink. This accompanies tock/tock#4695.
OpenOCD Changes
When initially adding this board, tockloader caused a number of bus faults that arose from attempting to read/write past the end of flash. I am not entirely sure why this has not come up before. My guess is that this has something to do with the lack of an OpenOCD board specific configuration for the stm32wle5jc. OpenOCD only has a target config (different than board config) for the stm32wle5xx (which can be a few different lengths for flash).
Quickly looking, it appears the other boards using OpenOCD have an OpenOCD board specific config (not just a target). Long story short, I bubbled up errors when attempting to r/w past the end of flash and added some exception handling to gracefully handle when this happens. Someone with a better understanding of OpenOCD/tockloader should sanity check this to make sure these changes are in fact necessary as this impacts all OpenOCD functionality, albeit minor.