Thanks for letting me know. I was trying to find a datasheet for the chip in question. I don't like the rcmx86 sleeping with a pin held high. I was actually messing around with this fix month's ago trying to fix another problem (couldn't get in to uf2 mode). Didn't work. Ended up swapping the pin arrangement.
No. The problem was in the original armoured dildo(Arduino) code.Was this RCMX86 issue only present with Fusee-UF2? Or does it happen with every other payload?
No. The problem was in the original armoured dildo(Arduino) code.
No they won't run in to the same issues. Switchboot uf2 is built with 2 components... The bin itself and the payload pusher (ie like tegrarcmsmash or fusee-gelee). The switchboot bin (just like Hekate) was not the source of the problem. The problem was in my implementation of the rcmx86 chip into the "payload pusher" software. But the overall problem is my memory. Back in the day, I was a decent programmer. But just a shell of that person now. At least when it comes to C. Life lesson: don't do drink, drugs or women... It makes you senile.So let's say one decides to use the hekate UF2 from the RCMX86 github. Will the user run into the same issues?
Sorry for so many questions, but I'm still deciding what's the best option with this chip.
No they won't run in to the same issues. Switchboot uf2 is built with 2 components... The bin itself and the payload pusher (ie like tegrarcmsmash or fusee-gelee). The switchboot bin (just like Hekate) was not the source of the problem. The problem was in my implementation of the rcmx86 chip into the "payload pusher" software. But the overall problem is my memory. Back in the day, I was a decent programmer. But just a shell of that person now. At least when it comes to C. Life lesson: don't do drink, drugs or women... It makes you senile.
It isn't much use to us or the end user. I think during design, it was meant to fix a different issue (we used to use an umbilical to vcc-in on m92t36) and this caused a couple of problems. The standard usb interface on the samd is fine.Drinking and drugs are ok, but no women
Will the firmware images from the creator of the RCMX86 also drain the battery during sleep like your current implementation?
I'm thinking about removing the USB IC, it seems to be useless anyway if I'm not mistaken.
It isn't much use to us or the end user. I think during design, it was meant to fix a different issue (we used to use an umbilical to vcc-in on m92t36) and this caused a couple of problems. The standard usb interface on the samd is fine.
Yes. I've seen one. Might have a pic somewhere.Did you ever see the RCMX86 without the USB IC ?
I see that the USB pins on the SAMD lead somewhere below the USB IC.
I did a little continuity check right now, but I can't seem to find the pins where they lead to - maybe you know more.
Yes. I've seen one. Might have a pic somewhere.
OK... @kiwihop
and everyone else...
It didn`t work because I compiled it for the Feather M0. I`m an idiot. Corrected UF2 now on my git.
All sorted.
Illl leave that up to you... Just back up your current uf2...So now tber's a real (little) drain battery with the rcmx86?
I didn't have usb issues... Better to not update?
Yeah. We had problems accessing UF2 bootloader. You remember? I was playing with D3 thinking that was part of the problem.D3 was used in the first diagrams for the joycon strap isn't it?
I changed it but I remember that it was working as a joycon strap
No. Because in all my UF2s for the RCMX86, D3 was unused. I enabled the (missing)LED on it for a time but got rid of that.But... Could the use of D3 in the past the way to do not get the known USB issues?
@mattytrog just for my understanding - let's say I remove this USB IC and hardwire the D- / D+ pads to the SAMD21, what UF2 images could I use?
The reason I ask, is because I don't want the chip to draw any power while in sleep mode, even if it's just a few µA as you said.
But for some reason I can't grasp the concept of these UF2 files for each chip.
All of them say, that they are "clones" of the trinket, but built specifically for the switch to be used as modchips.
So wouldn't that mean we can use ALL the UF2 files available on each chip ?
Example:
Let's say I modifiy the RCMX86 and remove the USB IC - would I still be able to use your UF2 files?
Or can I use the ones from the modchips github here ?: https://github.com/euclala/RCM-X86
My understanding is, that UF2 files are a program combined with the payload of choice.
And the program parts needs to know the pinout configuration of the chip.
So if I remove the USB IC, I shouldn't be able to use any payload from that github above, correct?
The difference is between pinouts on the chip.
If all boards used the same pinout and if all didn`t have a crystal oscillator connected, then yes. We could use the same file.
For example...
Trinket vs Feather: Same chip type(MCU) - One is a QFN/QFP 32, the other is a 48... pinouts completely different. Feather has a crystal, Trinket doesn`t.
Another example
Trinket vs RCMX86: Same type again... One is 32pin, one is 48pin. One has an extra IC, the other doesn`t. The wiring needs to be different for the RCMX86 just because of the extra IC.
The only one that is the same is the Rebug and Trinket. Different versions of that exist JUST so the correct chip is reported in straps_info.txt.
I wasn`t going to accomodate any extra boards at all. But Trinkets were scarce and it gives people more options.
If using JUST a 4 wire setup, it doesn`t really matter which file you use... Apart from the external crystal oscillator, there will be no LED indication due to pin 13 on most boards is the LED. But this "Pin 13" is a different physical pin on the chip. And your chip could spontaenously reboot due to capacitive pins set up to accomodate the very old methods of fitting.
Not really problems... Wondering why you need to use different UF2 files. That would make no difference whatsoever.Thanks for your reply !
I want to run some tests with this chip and different UF2 / Payloads.
What I want to try first is the following:
1) Remove USB IC and wire the 2 USB pins from the SAMD21 to the D- / D+ pads like you showed here:
2) Flash this hekate 4.6 UF2 as a base: https://github.com/euclala/RCM-X86/tree/master/hekate_ctcaer
3) Use UF2-Splicer.zip (awesome tool btw) - to switch the payloads in the "CURRENT.UF2" on the SAMD21
Do you see any problems there like you mentioned in your quoted post?
Thanks and regards!