topquark12

@pca006132 There's already a dedicated region specified in memory.x . Though the linker does not do anything with that region, and I don't think the linker generates a symbol for that space. I…

2021-01-12 17:22:56 +08:00

topquark12 commented on pull request M-Labs/thermostat#46

software_dfu

The stack is on CCM, the message is placed in RAM. I can try placing the msg in CCM, not sure what the reset behavior of CCM is yet.

2021-01-12 17:19:12 +08:00

topquark12 commented on pull request M-Labs/thermostat#46

software_dfu

> What happens to the TCP connection after a ``dfu`` command is sent? Currently the other end will have to terminate the connection. I've just copied what the reset command does. I can look…

2021-01-12 17:17:31 +08:00

topquark12 commented on pull request M-Labs/thermostat#46

software_dfu

> Why do we need a reset? What happens if we jump to the bootloader directly from the command handler in ``main.rs`` instead? The STM32 bootloader expects the chip to be in its default state when…

2021-01-12 17:12:31 +08:00

topquark12 commented on pull request M-Labs/thermostat#46

software_dfu

I thought that linker script is for a zynq? I am not sure where the linker script currently being used is placed, think it is packaged with one of the rust modules.

2021-01-12 17:10:19 +08:00

topquark12 commented on pull request M-Labs/thermostat#46

software_dfu

The linker currently does not actually do anything to the ram carved out for the dfu trigger message, and I beleive there's no symbol generated for that chunk of memory. I think I'll have to find…

2021-01-12 16:59:47 +08:00

topquark12 pushed to software_dfu at M-Labs/thermostat