These guys steer clear from anything that might give Nintendo any reasons to sue them.Has anyone asked CTCaer or SciresM for their expertise? Perhaps they would know of a workaround.
These guys steer clear from anything that might give Nintendo any reasons to sue them.Has anyone asked CTCaer or SciresM for their expertise? Perhaps they would know of a workaround.
Reset signals are usually active low. Meaning the SoC is under reset when low. You have to hold reset low for a minimum amount of time and then high so the CPU can start booting. I don't know the minimum reset time for the Tegra X1 but it's possibly in the datasheet.So, I hooked up RST to my Pico to see how RST works and when I set the output to HIGH the switch restarts, however, it only restarts if it changes from HIGH to LOW or from LOW to HIGH. How would I prevent the CPU from continuing? Do I really have to keep RST switching between HIGH and LOW?
Of course they are also trying for OLEDMaybe we can just use 1206 47R to reduce the whole size
Does someone is trying onto oled?
I don't have lite but oled yes
So basically the Switch won't boot as long as I keep RST low?Reset signals are usually active low. Meaning the SoC is under reset when low. You have to hold reset low for a minimum amount of time and then high so the CPU can start booting. I don't know the minimum reset time for the Tegra X1 but it's possibly in the datasheet.
I don't think it has anything to do with picofly, the file has a completely different size and is very different from the dumps that we have + picotool gave this:can anyone try to test and analyse this uf2 file and see whether it works
File RP2040ZERO-pico-v1.19.1-878.uf2:
Program Information
name: MicroPython
version: v1.19.1-878-g4598b89ce
features: thread support
USB REPL
frozen modules: neopixel, dht, ds18x20, onewire, uasyncio/stream, uasyncio/lock, uasyncio/funcs, uasyncio/event, uasyncio/core, uasyncio, _boot_fat, _boot, rp2
binary start: 0x10000000
binary end: 0x1004dc70
embedded drive: 0x100a0000-0x10200000 (1408K): MicroPython
Fixed Pin Information
none
Build Information
sdk version: 1.5.0
pico_board: pico
boot2_name: boot2_w25q080
build date: Feb 17 2023
build attributes: MinSizeRel
Can i test when return ti homecan anyone try to test and analyse this uf2 file and see whether it works
This above is not firmware (for the switch) if you are referring to that. Its a micropython. Not sure why he even posted thati just discovered that on one v2 switch it boots straight into hos, this is weird
Plus it uses “neopixel” which is for WLEDsThis above is not firmware (for the switch) if you are referring to that. Its a micropython. Not sure why he even posted that
Don t work all led Is offcan anyone try to test and analyse this uf2 file and see whether it works
Yes. It's a mapped address. 0x200200C0 ~ 0x200212F0 is loaded from .bin offset 0x1591C.Isn't that memory (SDRAM) address? I dont see any references in ghidra regarding that address anywhere.
Yes but not that mysterious, most of them are just the normal boot process. Like 0x10002608 is _retrieve_unique_id_on_boot, and triggered during the boot. The chip could hang in a loop check about hardware (e.g. XOSC) when not soldered to a unit, or say when peripherals are not correctly configured.It seems that rest of the functions are called when it receives some signal.
For example it does not call get_unique_id function at all while its not soldered to unit, chip just dies fast after boot