Internal modchip - SAMD21 (Trinket M0, Gemma M0, ItsyBitsy M0 Express) Guide, Files & Support

Discussion in 'Switch - Tutorials' started by mattytrog, Jun 20, 2018.

  1. popy

    popy Advanced Member

    Newcomer
    2
    Jul 31, 2018
    Austria
    @mattytrog: Any chance to get an version with just pushing the payload (without reset of simple-uf2) when usb strap is pulled?

    PS.: I want to build it myself, do i have just to install Arduino, download the source (main folder), select Trinket and build?
     
  2. mattytrog
    OP

    mattytrog Not on my watch.

    Member
    10
    Apr 27, 2018
    United Kingdom
    Pretty much.

    You need Arduino and adafruit sand support libs, flashstorage and dotstar libs.

    I'll build you one when I get home. Give me an hour
     
    popy likes this.
  3. popy

    popy Advanced Member

    Newcomer
    2
    Jul 31, 2018
    Austria
    Thanks, already built it, but how can ill make an UF2 out of the elf?
     
  4. mattytrog
    OP

    mattytrog Not on my watch.

    Member
    10
    Apr 27, 2018
    United Kingdom
    Chip in switchboot mode. Plug in. Select your chip from be menu. Select com port. Flash straight to chip.
     
  5. popy

    popy Advanced Member

    Newcomer
    2
    Jul 31, 2018
    Austria
    thanks, but i want to get the UF2.
    My switch isnt here at the moment :-)
     
  6. popy

    popy Advanced Member

    Newcomer
    2
    Jul 31, 2018
    Austria
  7. popy

    popy Advanced Member

    Newcomer
    2
    Jul 31, 2018
    Austria
    @mattytrog
    Have tried tod the following:

    void wakeup_usb() {
    delayMicroseconds(500000);
    //Set flag that loop() checks and if 1 it resends the payload
    ulLookForTegraBeforeSleep = 1;
    }

    and

    void loop()
    {
    //Should we send the payload?
    if(ulLookForTegraBeforeSleep == 1)
    {
    //Yes, do it :-)
    ulLookForTegraBeforeSleep = 0;
    lookfortegra();
    }

    //Sleep
    sleep(1);
    }

    Sadly, does'nt seems to work.
    Any ideas?
     
  8. mattytrog
    OP

    mattytrog Not on my watch.

    Member
    10
    Apr 27, 2018
    United Kingdom
    Yes. The reset is called from void wakeup. To do what you need, you basically need to reset all defines, start from void firstboot, then normal straps, set interrupts then look for tegrarcmsmash. I'll do it for you tonight. Trust me... I'm not the most efficient c programmer. I had a 25 year break from c and assembler.
     
  9. popy

    popy Advanced Member

    Newcomer
    2
    Jul 31, 2018
    Austria
    I have removed the 500ms delay in wakeup_usb():

    void wakeup_usb() {
    //delayMicroseconds(500000);
    dropstraps();
    normalstraps();
    SCB->AIRCR = ((0x5FA << SCB_AIRCR_VECTKEY_Pos) | SCB_AIRCR_SYSRESETREQ_Msk); //full software reset
    }

    Now it works on my switch like the following (with autoRCM for safety reasons):
    • Switch is powered off
    • I'll insert usb cable
    • Switch wents black and trinket power led on
    • unplug usb
    • SX OS screen pops up
    • Shortly the CHarging icon in the left < is this a problem!? Meaning that Big-N bootloader started?
    • CFW (SX OS) is booting and working
    My theory here, SX OS payload or loader is triggering the USB wakeup during first poweron, than theres the delay and then the straps are pulled during SX OS loader boot.
    Does this sounds plausible?
    Why is there a delay?

    pOpY
     
    Dougiejones likes this.
  10. popy

    popy Advanced Member

    Newcomer
    2
    Jul 31, 2018
    Austria
    Have also treid something like this:

    void loop()
    {
    if(ucTest)
    {
    ucTest = 0;
    lastCheckTime = 0;
    storedpayload = stored_payload.read();
    storedmode = stored_mode.read();
    newpayload = storedpayload;
    newmode = storedmode;
    startblink = 1;
    dropstraps(); //pull straps low
    normalstraps();
    firstboot(); //get flash memory status. If invalid, make valid.
    mode_check();
    lookfortegra();
    }


    Without success.
    I am trying now to reduce the delay...
     
  11. popy

    popy Advanced Member

    Newcomer
    2
    Jul 31, 2018
    Austria
    @mattytrog
    I have done timing tests with my switch and the wakeup_usb() delay (which was 500ms in your code and working on your switch).
    With the following results:

    250ms -> OK -> SX OS splash screen without menu -> shortly the battery icon -> Big-N Logo -> Horizon (SX OS CFW)
    350ms -> OK -> SX OS splash screen without menu -> shortly the battery icon -> Big-N Logo -> Horizon (SX OS CFW)
    400ms -> OK -> SX OS splash screen without menu -> shortly the battery icon -> Big-N Logo -> Horizon (SX OS CFW)
    425ms -> OK -> SX OS splash screen without menu -> shortly the battery icon -> Big-N Logo -> Horizon (SX OS CFW)
    437ms -> OK -> SX OS splash screen without menu -> shortly the battery icon -> Big-N Logo -> Horizon (SX OS CFW)
    443ms -> OK -> SX OS splash screen without menu -> shortly the battery icon -> Big-N Logo -> Horizon (SX OS CFW)
    446ms -> OK -> SX OS splash screen without menu -> shortly the battery icon -> Big-N Logo -> Horizon (SX OS CFW)
    450ms -> NOT OK -> SX OS menu -> press CFW in menu -> shortly the battery icon -> Big-N Logo -> Horizon (SX OS CFW)

    So it seems an timing issue to me -> your switch is different than mine on same FW (6.2.0).
    As you can see above it is working under 450ms for me also, no SX menu.
    So here are my final questions:

    • How did you determine this delay?
      Do you think we can reduce it to 250ms? (so we have ~200ms on my switch safe time)

    • Is it normal that the battery icon is displayed after pulling usb cable and SX OS splash screen?
      Or is this a sign that Big-N bootstack is running and can burn fuses?
      I have done my tests with autoRCM to prevent burn fuses if i fuck something up in the code :D
      Do you think its safe for me todo my tests without autoRCM?
    Thx
    pOpY
     
    Last edited by popy, Jan 11, 2019
    Dougiejones likes this.
  12. popy

    popy Advanced Member

    Newcomer
    2
    Jul 31, 2018
    Austria
    @mattytrog
    I have just done it -> disabled autoRCM, 250ms delay in UF2 and tested the following:

    • 5x: Boot normal -> SX OS CFW is always started (without boot menu)
    • 5x: Restarted horizon 5x times -> SX OS CFW is always started (without boot menu)
    • 5x: Press and hold vol+ after short PWR press -> SX OS menu is shown
    • 5x: launch briccmii from SX OS menu: its waiting for keys correctly and not doing any action itself (like it was before when vol+ was pressed -> unbrick)
    • 5x: power off switch -> insert unsb cable -> remove usb cable -> SX OS CFW is always started (without boot menu)
    And all that with no burnt fuses .
    I am on FW 6.2.0 which has 8 burnt fuses) but briccmii reads 6, which stands for firmware 5.0.0/5.1.0 :switch::yay3ds::yay3ds::yay3ds:
    So with 250ms in the function wakeup_usb all is working as it should for me.

    I have activated autoRCM to be 999999% safe :P

    pOpY
     
  13. mattytrog
    OP

    mattytrog Not on my watch.

    Member
    10
    Apr 27, 2018
    United Kingdom
    Right... Just got in. Going to be a long night tonight. Got 4 water damaged handsets come in and a Yaesu 857 Transceiver to repair and align :(

    Anyway... Lets press on.

    No. Fuses cannot be burned.

    I chose 500mS to allow for faulty cables. Some cables have breaks. If they are pulled out slowly, data pins could be connected while pwr + gnd pins are not connected or visa versa.

    The testpoint that we are using is actually an input to the BQ24193 for a battery thermistor. The signal we are using is the bias to this thermistor.

    I can change the value to suit. I plan on working on the code substantially tonight at some point.

    Yes. It is normal that the battery is connected. To confirm, one can disable the straps (thus burning fuses) and plugging in to USB when the power is off. Same behaviour.

    Just to clarify... Don`t piss around with the switchboot code. That is saving your fuses and like I said... Has been tested thoroughly. As long as you are using the both file of switchboot, you are safe.

    But yes. It isn`t crucial the usb delay is 500mS. It was just a ballpark figure to provide some "bounce" protection if all pins in the USB lead are not connecting properly. Thats all.

    Experiment as you wish.

    — Posts automatically merged - Please don't double post! —

    If you have done your testing with autoRCM enabled, then that is not much good. The 500mS works fine for me but I`ll commit 250mS
     
    popy likes this.
  14. mattytrog
    OP

    mattytrog Not on my watch.

    Member
    10
    Apr 27, 2018
    United Kingdom
    @popy

    Going back to your previous point earlier about just pushing payload... I think I`d rather keep it as it is. The most obvious reason is that when the console is off and it is unplugged, because there is no autoRCM, the Nintendo bootloader will run and burn fuses.

    So that is a big nono. That defeats the object of this exercise. How is the bootloader going to trigger RCM? It can`t.

    Resulting in normal boot, burning fuses.

    Nice idea though.

    Those straps have to be grounded STRAIGHT AWAY. That is only possible from running the bootloader first.

    However, I`m putting code "switches" in (#define ENABLE_USB_STRAP) and maybe add a new couple of "modes" to enable or disable the strap with a button press.

    And changing the delay to 250mS. Thank-you for the suggestion!
    I want that delay there just as a "debounce" as I said earlier in case a wobbly connector causes problems, resulting in a device stuck in RCM.

    I`m not happy about it as it contradicts pulling the straps low straight away. Think I might just do it on falling.

    Fancy testing?
     
    Last edited by mattytrog, Jan 12, 2019
    Dougiejones and popy like this.
  15. popy

    popy Advanced Member

    Newcomer
    2
    Jul 31, 2018
    Austria
    Thanks for clearing things up. My tests was wothout autoRCM! Just activated it afterwards.
    So yes, 250ms is good here.

    pOpY

    Gesendet von meinem ONEPLUS A6013 mit Tapatalk
     
  16. mattytrog
    OP

    mattytrog Not on my watch.

    Member
    10
    Apr 27, 2018
    United Kingdom
    popy likes this.
  17. popy

    popy Advanced Member

    Newcomer
    2
    Jul 31, 2018
    Austria
    Whats this?

    Gesendet von meinem ONEPLUS A6013 mit Tapatalk
     
  18. mattytrog
    OP

    mattytrog Not on my watch.

    Member
    10
    Apr 27, 2018
    United Kingdom
    Oh... Just a switch which eMmc had a few issues!

    Posted in wrong thread actually.
     
    popy likes this.
  19. popy

    popy Advanced Member

    Newcomer
    2
    Jul 31, 2018
    Austria


    Do you planing to reduce the 500ms wakupup_usb to 250ms?

    Gesendet von meinem ONEPLUS A6013 mit Tapatalk
     
  20. Dougiejones

    Dougiejones Member

    Newcomer
    1
    Jan 13, 2019
    United States
    Hi,

    if you permit here's my feedback with the new universal method + Simple-UF2 v0.9.4.uf2.
    I'm facing the same issue as popy that is only booting at the SX OS Option menu from startup.

    My setup :
    • Neon Switch from stock upgraded onto 6.2.0 ofw
    • Joycon modded
    • Trinket M0 flashed with switchboot bootloader then Trinket_Rebug_Both.uf2
    • Vol+ strap and USB disconnect strap fitted
    If this could help
     
Loading...