Teensy 4.1: extra flash, optional external RAM not addressable #86
Comments
|
Note that this issue doesn't affect usage of the SD card on the Teensy 4.1. I believe using the SD card will need a uSDHC driver. |
|
How would one go one to enable this? I'm actually running into hard memory limits whilst speaking on the Teensy as I had assumed to have at least 1mb of RAM available for the Heap implementation. |
|
If you're interested in hardware modifications that increase RAM, the Teensy 4.1 supports external RAM. Here are the recommended parts and installation instructions. Otherwise, the on-chip RAM (OCRAM) is the same for both Teensy 4 models.
Sorry, but I'm not sure we can provide 1MB of RAM solely for heap. The official Teensy 4 runtime provides up to 512KB of OCRAM for the heap. See the Teensy 4.1's memory map, here. #110 proposes something similar for this implementation. |
|
Ah thank you. Now I understand the title better. Sorry for posting it in the wrong thread. I assumed it was different to the Twensy 4.0 as the flash has increased immensely in comparison. |
|
@mciantyre Should it suffice to replace this line
with
for the Teensy MicroMod? (EDIT: I suppose the FlexSPI Configuration Block in Also, since we're also talking about RAM here... I got my FlexIO+DMA LCD driver working, and implemented a driver for Slint, and it works:
But that's just running the small demo here: https://github.com/slint-ui/slint-mcu-rust-template/blob/225ab463511411ffb4b26f71b77e2215717e8667/ui/appwindow.slint I wanted to try running their printer UI demo, but I run into linking issues: Tried adding this to [profile.release]
opt-level = "z"
lto = truebut still no luck. Any advice? |
|
They run the demo on a STM32H735IGK6U MCU (564kB of SRAM) and a Raspberry Pi Pico (264kB SRAM), so it seems like there should be some way to pull this off on the TMM. Certainly they aren't doing something like keeping code on flash instead of SRAM 🤔 I figured I'd do something like |
diff --git a/build.rs b/build.rs
index 201ff96..3f74126 100644
--- a/build.rs
+++ b/build.rs
@@ -13,7 +13,7 @@ fn main() {
.stack(Memory::Dtcm)
.stack_size(16 * 1024)
.vectors(Memory::Dtcm)
- .text(Memory::Itcm)
+ .text(Memory::Flash)
.data(Memory::Dtcm)
.bss(Memory::Dtcm)
.uninit(Memory::Ocram)This lets me compile and link without error, but flashing the device doesn't give any indication that anything is happening (no RTT output, and nothing on screen). Dunno if I'm either missing something there, or if the RT1062 needs to be configured differently to run from flash, or something else. |
|
Well done 🎉 very cool to see a UI framework running on these MCUs! Yup, I'd expect changes to the flash size in the From the unmodified runtime: Lines 6 to 10 in 6f38334 Every FlexRAM bank is 32 KiB of some kind of RAM. If you add a bank to ITCM, you'll get an additional 32 KiB for instructions. But, the chip only has 16 banks. So if you add a bank to ITCM, you'll need to take a bank away from DTCM. I'm hoping that there's a balance of FlexRAM banks where those "section '.text' will not fit in region 'ITCM'" errors go away. An extreme alternate approach: How about putting everything into OCRAM? We can express that with the RuntimeBuilder::from_flexspi(Family::Imxrt1060, 1984 * 1024)
.flexram_banks(FlexRamBanks {
ocram: 16,
itcm: 0,
dtcm: 0,
})
.heap(Memory::Ocram)
.heap_size(16 * 1024)
.stack(Memory::Ocram)
.stack_size(16 * 1024)
.vectors(Memory::Ocram)
.text(Memory::Ocram)
.data(Memory::Ocram)
.rodata(Memory::Ocram)
.bss(Memory::Ocram)
.uninit(Memory::Ocram)
.linker_script_name("t4link.x")
.build()
.unwrap();Naively, I expect this XIP configuration would work. But, I haven't played around enough with XIP to know its proper setup and limitations. (If I remember correctly, whenever I tried XIP on my 1010EVK, I'd eventually fault with undefined instructions.) |
|
Thanks @mciantyre for your help thus far! I tried again with the XIP config, but using the simple demo UI, and that did work. So I decided to put aside the big printer UI demo and see if I could reproduce my problems by just duplicating the text and button field on that UI; sure enough, past a certain number of elements (~10 text boxes or buttons) the program crashes again. Attached a debugger and found that when it does fail, it happens right when making a function call. Execution jumps straight to the HardFault handler. So my hunch is something like I can't call a function if the address is too high. My OOM handler isn't called, so it's not that (and besides, this is really early on in the initialization of the program -- not much has or will be allocated at point). In case it was a problem with XIP, I also tried with this config (only slightly modified from your suggestion): #[cfg(feature = "rt")]
fn main() {
use imxrt_rt::{Family, FlexRamBanks, Memory, RuntimeBuilder};
RuntimeBuilder::from_flexspi(Family::Imxrt1060, 1984 * 1024)
.flexram_banks(FlexRamBanks {
ocram: 16,
itcm: 0,
dtcm: 0,
})
.heap(Memory::Ocram)
.heap_size(16 * 1024)
.stack(Memory::Ocram)
.stack_size(16 * 1024)
.vectors(Memory::Ocram)
.text(Memory::Ocram)
.rodata(Memory::Flash) // <--- rodata still won't fit, so put it in flash
.data(Memory::Ocram)
.bss(Memory::Ocram)
.uninit(Memory::Ocram)
.linker_script_name("t4link.x")
.build()
.unwrap();
}I feel like it's sooo close! If you have any other suggestions, please do let me know. Thanks! |
|
Realized it could be a stack overflow, so I tried doubling up on stack ( So my next order of business is figuring out how I can get a heads-up when the stack overflows, because that's super not fun to debug. |
|
Awesome! Good call putting read-only data into flash. I've generally had better luck fetching data over FlexSPI than fetching instructions over FlexSPI. One stack overflow detection strategy that comes to mind is to use the MPU. A MemManage fault could be that heads-up. But for the MPU to be effective, I think we'd need to define all of the accessible memory regions. I'd been thinking about exposing all the memory regions through (My suggestion ignores a potential problem of "what does a helpful MemManage / HardFault response look like when we're out of stack?") |
|
@mciantyre I'll have to read up on the MPU -- thanks for the suggestion! Also, since you might be interested, a video of me running their printer demo UI: https://twitter.com/charlesstrahan/status/1630026224356474881 Just recently wrapped up the last pieces I needed to get everything working :). Hoping to soon tease apart the 8080 bus, Slint backend, Goodix touchscreen and RA8876 (and ILI9486) controller code into separate crates and opensource everything. After that, I'm hoping to design a PCB to facilitate direct connection to this display (and maybe a couple others), so that someone wanting to write fancy (and responsive) UIs for embedded projects can hit the ground running from day 1. |
The
teensy4-bspsupports both Teensy 4.0 and 4.1 boards. We achieve this with a single linker script. However, the common support means that we are not using the Teensy 4.1'sUsers who need more than ~2MB flash for their Teensy 4.1 programs, or who want to use the pads for extra RAM and flash, may find that today's BSP doesn't support these features.
This issue tracks support for extra storage on the Teensy 4.1.
The text was updated successfully, but these errors were encountered: