Hi Matty,
the detection in switchboot v1 for the straps is it based on hardware detection of straps connected or the config made in the eeprom(Part1) ?
if the joycons are not connected the strap detection does not work it says not detected for joycon strap. but both switches get me vol+ strap not detected :-(
both were flashed with *JOYCON_VOLUME.uf2 and TRINKET_REBUG_SWITCHBOOT_PART2_V1.UF2
after some reboot it says all 3 straps detected yes, i don't know the circumstances why it detect wrong or if my cables are not stable but it's not as reliable as i thought
does pressing minus at the bootup influence the detection of the straps ?
could you please explain what modchip payload setting and mode settings means and the possible values ?
Right... This is how the strap detection works...
Once we have sent the payload, you cannot change values on-screen ( you could, if you fit extra straps, maybe to serial, or hijack the USB port - though that would prevent anything else connecting to it.)
The very very first boot, there is a "runonce" section, that will check for the USB strap and return true if there is voltage on USB bus (ie when a cable is plugged in). So, for example, if you disconnect STRAIGHT after flashing, the strap might not be detected. This value gets locked and the code is never ran again... UNLESS you reflash the UF2 or use the EEProm reset in the vol+ button combo.
The vol+ strap... The moment you press vol+, at ANY time, this will update the value, save it to the chip and on the NEXT reboot, the info will be updated.
Same for the joycon strap. When you plug a joycon in, a potential is sensed on "pin 10" and this value is stored to eeprom... Again, once you reboot, it will show.
All values are "permanently" locked, as it is not necessary to keep looking for them once detected.
This is exactly how the "multi-payload" works (excluding where multiple payloads are in the actual chip).
In a multi-payload situation...
Example... The chip is looking for "payload1.bin"
So the bytes that are sent are (im paraphrasing here) - 0x p, 0x a, 0x y, 0x l, 0x o, 0x a, 0x d" then if payload1 is selected, 0x31 is sent... Payload2.bin, would be 0x32 etc etc. This chopping and changing allows similar code to be reused and save having duplicated parts of a c array on the chip, therefore giving you more space.
So... If you want all straps to show correctly, when you first flash the UF2, keep USB connected, connect a joycon and press vol+ at least once. Then reboot the chip / console.
If your straps are correct, they will NOW be updated.
Like I say, it is impossible to change the cosmetic values once the payload has sent. The only way around that is implementing some kind of serial communication. But this will more-than-likely push the stack over the 126296 limit.
"But how does it update from the other direction then?" I hear you ask...
Simple...
The payload is pushed byte-to-byte to a buffer prior to triggering the exploit. During this "byte-by-byte" stream, the appropriate values for straps are gathered, and the "byte-stream" is chopped and modified on the fly.
So different values are sent to the buffer prior to exploit running.
