Hacking COMPLETED My dongle project, internal/external SAMD Loader with CR2032 Holder

[electronrancher]

Hmm, that seems quite high. I wonder if some power could be saved by disabling some of the systems of the SAMD21 that aren't needed for this process?

For your LED, you could always just stick it on a PWM output and dim it that way so a hardware change isn't needed. Then the user could set the brightness to whatever they like when compiling the UF2

Supercaps are super rad for sure, but there are a lot of "gotchas" I wasn't previously aware of and a bunch of math involved I had to learn. It's definitely not the best solution for every project. It was fun for me but I'm a huge nerd.

The cheapest I've found the DotStar-2020s at a legitimate dealer is $40/100 at Mouser which is quite expensive still. The APA-102 chip takes around 1-2mA at idle so I'd really like to ditch it. I found this little guy on LCSC (my new best friend) for dirt cheap:

https://lcsc.com/product-detail/Light-Emitting-Diodes-LED_FM-B1515RGBA-HG_C113717.html

It costs 3 cents in quantities of one and if you only want one color at a time, you can just put a single 660Ω resistor on the cathode and run it directly off of the output pins of the ATSAMD21. You might even be able to get away with 2 colors at a time at a slightly reduced brightness.

--------------------- MERGED ---------------------------


But... so shiny...


Ow.


Worth it.

I think that current is average, or even better than. I think the sam fusee code says 10 or 12mA when using trinket. You could probably disable some systems, but I don't know if anything unecessary is even on in that code. It didn't seem to bad for me, as the use time is really quite low - mattytrog's new code only searches for 1 second before going to sleep, you just need to change the order of operations. In the original sam code, you started up the dongle then went into RCM. To use mattytrog's code, you'd want to enter RCM and then power up the dongle. If it comes up, sends within 1 second and goes to sleep - that's pretty power efficient for a simple change in sequence.

I like the idea of using common cathode rgb - much cheaper and we're in control of the current draw.

 

[Canna]

I think that current is average, or even better than. I think the sam fusee code says 10 or 12mA when using trinket. You could probably disable some systems, but I don't know if anything unecessary is even on in that code. It didn't seem to bad for me, as the use time is really quite low - mattytrog's new code only searches for 1 second before going to sleep, you just need to change the order of operations. In the original sam code, you started up the dongle then went into RCM. To use mattytrog's code, you'd want to enter RCM and then power up the dongle. If it comes up, sends within 1 second and goes to sleep - that's pretty power efficient for a simple change in sequence.

I like the idea of using common cathode rgb - much cheaper and we're in control of the current draw.

thanks rancher you just finished me brain off
Goodnight budd were continue tomorrow

 

[MatinatorX]

I think the best case scenario is if the dongle is only powered when connected to something that's in a USB slave state or when getting an external 5V VCC. Then it will power on when you plug it in to a Switch in RCM mode (when the Switch USB is in slave mode), then power itself off once the payload is injected (when the Switch USB goes back into host mode). @jcrorxp shared with me that a USB device in slave mode will pull up D+ to 3.3v as part of speed negotiation and it will stay that way. I finally finished my research on this and just confirmed myself that D+ indeed was 3.3v in RCM mode and dropped to 0v once the payload was injected. I have VCC snipped on my Type C to Micro-B cable and made sure to confirm that the 3.3v was not coming from the Trinket M0 I was using. In fact you can measure this 3.3v without anything connected but a USB Type C breakout.

It should be possible to hijack the 3.3v signal from the Switch, or an external 5v from an SWC programmer/PC/whatever to turn on the dongle. You just need to send both signals through a Schottky to the base of an NPN transistor, then run your VCC through that before it hits your ATSAMD21. This way the dongle will only be powered on when connected to a computer or SWC programmer (when you will have external 5V and not using the battery) or when Switch is in RCM mode (D+ pulled high to 3.3v). I'm working on a revision of my dongle right now that does exactly that. I'll share the schematic here as soon as I can confirm it works if anyone is interested.

I should note that USB Type C sometimes doesn't keep VCC hot all the time like earlier USB revisions did. Some devices do, but the spec is very specific about which devices can and can't keep VCC hot. For example, the Type C port on my motherboard has VCC cold. The Switch does too. Type C often requires some power negotiation circuitry - something I did not find out about until now. It's looking like either a 56KΩ pull-up from CC to VCC or a 5.1 KΩ pull-down to ground is required to get VCC hot at legacy power delivery levels (500mA/5v). I'm playing around with it right now to try and get my Trinket M0 powered off of my Type C port.

 

[MatinatorX]

Update: It was a 5.1 KΩ pull-down to ground

 

[electronrancher]

Tell me about this mystical 5k.. This requests power from the USB C?

 

[MatinatorX]

Tell me about this mystical 5k.. This requests power from the USB C?

Pretty much yeah. USB Type C has a bunch of ways of identifying the power requirements and capabilities of hosts, chargers and slave devices. Until the power requirements are known, it just doesn't send power (in most cases anyways). For legacy devices, a pull-up / pull-down resistor is all that's needed on CC1 to identify to the host that it's capable of receiving a certain voltage up to a certain current. Anything under 15W total power counts as a legacy device, at least in terms of power requirements. Anything that needs to use more power (up to 100W) is required to do some fun stuff with the USB-PD pin, which is CC2, or whatever CC pin you didn't use for CC1 (since USB Type C is reversible). USB-PD is an actual communications protocol that transmits power requirements in a way far too fancy for me to bother to learn.

If you want to read the full spec (I didn't) you can find it here: http://www.usb.org/developers/docs/

A much better summary and the one I read to get a better understanding of things was this: http://www.ti.com/lit/wp/slly016/slly016.pdf

If you just want to make some damn cables, man, and don't have time for nerd novels, a nice cheat sheet is here: https://www.chromium.org/chromium-os/cable-and-adapter-tips-and-tricks

And of course the pinout for USB Type C is pretty helpful and can be found on good ol' Wikipedia: https://en.wikipedia.org/wiki/USB-C#Connector_pinouts

I am by no means any kind of an expert, but I did spend most of this evening reading the above and soldering tiny wires to Type C breakouts for testing and got it to work in the end.

 

[electronrancher]

Pretty much yeah. USB Type C has a bunch of ways of identifying the power requirements and capabilities of hosts, chargers and slave devices. Until the power requirements are known, it just doesn't send power (in most cases anyways). For legacy devices, a pull-up / pull-down resistor is all that's needed on CC1 to identify to the host that it's capable of receiving a certain voltage up to a certain current. Anything under 15W total power counts as a legacy device, at least in terms of power requirements. Anything that needs to use more power (up to 100W) is required to do some fun stuff with the USB-PD pin, which is CC2, or whatever CC pin you didn't use for CC1 (since USB Type C is reversible). USB-PD is an actual communications protocol that transmits power requirements in a way far too fancy for me to bother to learn.

If you want to read the full spec (I didn't) you can find it here: http://www.usb.org/developers/docs/

A much better summary and the one I read to get a better understanding of things was this: http://www.ti.com/lit/wp/slly016/slly016.pdf

If you just want to make some damn cables, man, and don't have time for nerd novels, a nice cheat sheet is here: https://www.chromium.org/chromium-os/cable-and-adapter-tips-and-tricks

And of course the pinout for USB Type C is pretty helpful and can be found on good ol' Wikipedia: https://en.wikipedia.org/wiki/USB-C#Connector_pinouts

I am by no means any kind of an expert, but I did spend most of this evening reading the above and soldering tiny wires to Type C breakouts for testing and got it to work in the end.

Thanks, that's an excellent description! So my mysterious B-C cable must be doing some magic inside, I may rip it apart and see what the heck is going on, I had no idea that a request resistor was needed. Fascinating!

 

[starburst]

Oh, man, I am loving this thread!
It is like watching those old kung-fu films: no idea what they say, but the sequences are pure fun.

 

[MatinatorX]

Thanks, that's an excellent description! So my mysterious B-C cable must be doing some magic inside, I may rip it apart and see what the heck is going on, I had no idea that a request resistor was needed. Fascinating!

This is basically how I went from 4 working Type-C cables to none

If you're plugging into anything besides a USB Type C host, no fancy stuff is needed and VCC will always be hot. It's just the Type C 3.1 spec that throws wrenches into all the gears. If your B-C cable powers your Trinket M0 on it's own from your Switch, you've got that magic 5.1K resistor between CC1 and GND. If not, I personally think the hand twisted 10K-series parallel 220R-series MacGyver is quite stylish

--------------------- MERGED ---------------------------

Oh, man, I am loving this thread!
It is like watching those old kung-fu films: no idea what they say, but the sequences are pure fun.

The difference here is that we're either both winning or we're both losing depending on who you ask...

At this rate we're going to have to start a sister site called... BGATemp.

 

[electronrancher]

Oh, man, I am loving this thread!
It is like watching those old kung-fu films: no idea what they say, but the sequences are pure fun.

That's funny, I was just hearing old kung fu movies while working on boards in the basement.

Are you... my judge?

It's just.. you should be punished.

I'm going to chop off your arm, so are you ready?

 

[xeswitched]

This is basically how I went from 4 working Type-C cables to none

If you're plugging into anything besides a USB Type C host, no fancy stuff is needed and VCC will always be hot. It's just the Type C 3.1 spec that throws wrenches into all the gears. If your B-C cable powers your Trinket M0 on it's own from your Switch, you've got that magic 5.1K resistor between CC1 and GND. If not, I personally think the hand twisted 10K-series parallel 220R-series MacGyver is quite stylish

--------------------- MERGED ---------------------------



The difference here is that we're either both winning or we're both losing depending on who you ask...

At this rate we're going to have to start a sister site called... BGATemp.

You've intrigued me to remove my CR2032 and try to wire the resistor to the board. This essentially would provide me a way to just place the trinket in the switch and RCM will power it?

 

[MatinatorX]

You've intrigued me to remove my CR2032 and try to wire the resistor to the board. This essentially would provide me a way to just place the trinket in the switch and RCM will power it?

Unfortunately it's not quite that easy. The Switch does not provide 5V on the Type C port unless it's in host mode, for example when it's booted into Horizon. RCM mode puts the Type C port into slave mode, at which point VCC 5V turns off, as it expects the host to provide its own power. Else our life would be a whole lot easier

EDIT: Also I'm assuming you're using a Type C to Micro USB adapter if you're using a Trinket M0 or similar. If so, it's very likely your cable has that resistor already.

 

[xeswitched]

Unfortunately it's not quite that easy. The Switch does not provide 5V on the Type C port unless it's in host mode, for example when it's booted into Horizon. RCM mode puts the Type C port into slave mode, at which point VCC 5V turns off, as it expects the host to provide its own power. Else our life would be a whole lot easier

Okay sticking to current method then.

 

[electronrancher]

This is basically how I went from 4 working Type-C cables to none

If you're plugging into anything besides a USB Type C host, no fancy stuff is needed and VCC will always be hot. It's just the Type C 3.1 spec that throws wrenches into all the gears. If your B-C cable powers your Trinket M0 on it's own from your Switch, you've got that magic 5.1K resistor between CC1 and GND. If not, I personally think the hand twisted 10K-series parallel 220R-series MacGyver is quite stylish

--------------------- MERGED ---------------------------



The difference here is that we're either both winning or we're both losing depending on who you ask...

At this rate we're going to have to start a sister site called... BGATemp.

This is basically how I went from 4 working Type-C cables to none

If you're plugging into anything besides a USB Type C host, no fancy stuff is needed and VCC will always be hot. It's just the Type C 3.1 spec that throws wrenches into all the gears. If your B-C cable powers your Trinket M0 on it's own from your Switch, you've got that magic 5.1K resistor between CC1 and GND. If not, I personally think the hand twisted 10K-series parallel 220R-series MacGyver is quite stylish

--------------------- MERGED ---------------------------



The difference here is that we're either both winning or we're both losing depending on who you ask...

At this rate we're going to have to start a sister site called... BGATemp.

Definitely both winning is my vote!

 

[electronrancher]

@mattytrog - thanks a ton for the multiloader code. I didn't quite steal it directly, but rather remixed it for my board. However, your source was an invaluable reference and I'll attribute properly on github.

 

[mattytrog]

@mattytrog - thanks a ton for the multiloader code. I didn't quite steal it directly, but rather remixed it for my board. However, your source was an invaluable reference and I'll attribute properly on github.

Very welcome mate.

Check out the cleaned up code tomorrow. I did the other in a rush!

Very simple implementation. I've got SD card support working of sorts too. But it's very dirty. Might get round to finishing it one lifetime!

Glad it helped

 

[xeswitched]

Very welcome mate.

Check out the cleaned up code tomorrow. I did the other in a rush!

Very simple implementation. I've got SD card support working of sorts too. But it's very dirty. Might get round to finishing it one lifetime!

Glad it helped

What is this multiboot code I read about?...

 

[electronrancher]

What is this multiboot code I read about?...

It stores 3 payloads (hekate, ReiNX, and SX) and allows you to choose different ones without flashing. Right now, it is using D1 as select, but it sounds like mattytrog has something cooking that will be reset-only.. Very interesting!

Most of the discussion is in the DIY dongle thread by Canna
https://gbatemp.net/threads/d-i-y-payload-dongle-modchip-injector-thread.514577/

BTW - you should post your build to the thread, man! it's very slick!

 

[MatinatorX]

It stores 3 payloads (hekate, ReiNX, and SX) and allows you to choose different ones without flashing. Right now, it is using D1 as select, but it sounds like mattytrog has something cooking that will be reset-only.. Very interesting!

Most of the discussion is in the DIY dongle thread by Canna
https://gbatemp.net/threads/d-i-y-payload-dongle-modchip-injector-thread.514577/

BTW - you should post your build to the thread, man! it's very slick!

I'll be really interested to see how this works. I tried to think of a way to do this with only the reset button the other day, but couldn't come up with anything that wouldn't result in payload roulette every time you plugged in the dongle

I was hoping that the reset button only reset the MCU once you let go, and it does, but it also freezes up the MCU while it's held down so it's no good for switching payloads that way.

EDIT: Maybe a counter of some sort? If you reset the dongle in the first second of being on it'll switch to the next payload?

 

[electronrancher]

I'll be really interested to see how this works. I tried to think of a way to do this with only the reset button the other day, but couldn't come up with anything that wouldn't result in payload roulette every time you plugged in the dongle

I was hoping that the reset button only reset the MCU once you let go, and it does, but it also freezes up the MCU while it's held down so it's no good for switching payloads that way.

EDIT: Maybe a counter of some sort? If you reset the dongle in the first second of being on it'll switch to the next payload?

That's a pretty good idea! I figured I'd have to go hacking the uf2 boot loader. My proposal would be to click reset and hold while the boot loader cycled through 1, 2, 3.

Then, gotta pick a common memory location so the firmware can read it out.

Problem is, click and hold is a bit uncomfortable to do, at least in my opinion.

Your plan is better, but it might also be tricky because clicking again too fast would drop into boot loader. Maybe 2 seconds?