Using arg001's sophisticated technique I get this output:
Based on Table 11 in the RP2350 datasheet (section 2.2.3), that puts the core0 stack in SRAM9, or scratch_y, and the core1 stack in SRAM8, or scratch_x. As one would expect from the memmap scripts.
The application makes use of both of the local variables whose addresses are shown here, and they work as expected. So I conclude that the code shown further up in the thread does not turn off SRAM1, despite the PICO_OK return value from powman_set_power_state(). Not only that, but it would probably be bad if it did, without changing the stack location.
Call me a broken record, but I'm still wondering about how to use the hardware_powman API. This brings up even more questions.
Code:
core0 stack around 20081FF4core1 stack around 20080FC8The application makes use of both of the local variables whose addresses are shown here, and they work as expected. So I conclude that the code shown further up in the thread does not turn off SRAM1, despite the PICO_OK return value from powman_set_power_state(). Not only that, but it would probably be bad if it did, without changing the stack location.
Call me a broken record, but I'm still wondering about how to use the hardware_powman API. This brings up even more questions.
- Why did I get the PICO_OK return value? Isn't this evidence that the SRAM1 power domain was, in fact, not turned off?
- So how do you change the power state with hardware_powman?
- Can a small app, that doesn't need so much memory, take advantage of turning off SRAM? Does that require a custom memory map? Is it just as well to turn off SRAM banks individually with SYSCFG MEMPOWERDOWN, as we did with the RP2040?
Statistics: Posted by slimhazard — Mon Aug 26, 2024 4:25 pm