Signal to firmware not to load app from flash

[mchack-work]

Firmware is getting the possibility to load a preloaded app from flash. See #215

We need a way to indicate to the firmware that the app should be loaded from the client instead of from flash.

[mchack-work]

Decision on meeting on 2024-05-16 to try to use a touch hold for this function. See attached PR.

Needs a software test. See #223

[dehanj]

Started to investigate this, the touch sensor have a ~300 ms start up time, see attached picture. During this time the output from the touch sensor will be high, regardless of a touch or not. It seems to go low when it is ready.
This is most likely some power up sequence the touch IC needs, maybe calibration, maybe something else.

On top of this, the sensor is not registering a touch that started before the end of these 300 ms, meaning holding on the touch area and powering up the device, will not register a touch. The touch needs to start when the touch IC is ready.

[SallSim]

We will implement this with a protocol.

[mchack-work]

Our UX spec says we will use a client/app protocol request to ask for a system reset to load a new app from the client. The hardware support for system reset already exist (TK1_MMIO_TK1_SYSTEM_RESET).

However, we still have no way of communicating the device app's intent with a system reset to the firmware. The intent might be to just do a system reset because it's finished with it's work and start everything again, but it might also mean that the device app is calling system reset because the client asked it to, in order to load a new app from the client.

This means that, right now, the firmware will happily just start the preloaded app again and again. Clearly we need some way of communicating this intent to the firmware.

A couple of options:

1. Extend the hardware system reset API to include the intent.
2. Use some part of RAM to indicate intent.
3. Use touch and finger detected instead, even though we have to wait until the sensor is ready and probably blink until a timeout, waiting for a touch.

For 2 above we might want to use some reserved way of doing this, like calling another system call in the firmware, and store the intent in FW_RAM instead, but that needs analysis.

Any more options? What's a good way forward? What are the threats, if any?