TX switch may prevent transponder from booting

[peterantypas]

The current design (including board revs shipped in the kit) directs the "TX_OFF" signal to the GPIO PA12. This was an unfortunate choice, as it turns out, because this pin is USB D+ and the effect of the "TX off" setting is for it to be pulled down to GND hard via a buffer MOSFET.

This causes some boards to hang and draw a significant amount of current during POR. But not every board does this.

The best workaround is to always keep the breakout switch to "TX on" position during power-up.

[gah67]

I was just looking at the NMEA0183 breakout schematic to see if a capacitor could be added to make an RC circuit to delay the +5V signal and I have a query - isn't the 'TX_DISABLE/3.1B' on the 'wrong' side of R9? Where is is is not current limited is it??

----- On 13 Jul, 2021, at 20:54, Peter Antypas @.***> wrote:

The current design (including board revs shipped in the kit) directs the "TX_OFF" signal to the MCU's PA12 GPIO. That was an unfortunate choice, as PA12 is USB D- in the context of the ROM bootloader which runs on power-up. When that I/O is pushed high during power-up, it prevents the bootloader from passing control to the application.

The current workaround is to always keep the breakout switch to "TX on" position during power-up. Even the latest board (10.9) has this issue.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, [ https://github.com/peterantypas/maiana/issues/72 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/ANPRIFKOICRNP5WEYDQGY3TTXSKWFANCNFSM5AKAQVGQ | unsubscribe ] .

[peterantypas]

R9 was there to prevent a floating signal during post-SMT testing (prior to soldering the switches). But the circuit has to change now to introduce an RC delay. Even a very short (200ms) delay seems to work when I test this manually.

[peterantypas]

So the solution is to redesign both the USB and NME0183 breakouts. I will email the folks who bought kits (there's quite a few already) and explain. I'm also changing the NMEA2000 breakout (which isn't released yet).

[peterantypas]

I can validate this by reworking a USB breakout board. I will cut this trace on the bottom and scrape solder mask to make an RC delay.

[gah67]

That's a very handy via!

----- On 14 Jul, 2021, at 16:37, Peter Antypas @.***> wrote:

I can validate this by reworking a USB breakout board. I will cut this trace on the bottom and scrape solder mask to make an RC delay.

[ https://user-images.githubusercontent.com/1565933/125650364-57cc9b71-a365-41fe-b3d8-a25ec56d657f.png ]

— You are receiving this because you commented. Reply to this email directly, [ https://github.com/peterantypas/maiana/issues/72#issuecomment-879997410 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/ANPRIFPRJ4H5BCRCRTXM2Z3TXWVLRANCNFSM5AKAQVGQ | unsubscribe ] .

[peterantypas]

I have confirmed that all STM32L4x series MCUs drive PA12 high during reset, and shorting it to GND causes all kinds of problems. Time delay is the only possible short term fix. Long term fix is to redesign the main transponder board.

[peterantypas]

Turns out that this is more of a POR glitch:

Yellow is NRST, purple is PA11, blue is PA12, green is BOOT0.

[peterantypas]

PA12 glitches up to 2V during power-up. But this condition expires within 400us so a delay will take care of it.

In typical ST fashion, none of these things are documented. The errata contains approximately 50% of what's wrong with each chip. They still haven't admitted the serious silicon bugs I found in the F469 series back in '17.

[peterantypas]

Alright, 1.1K + 1uF RC delay took care of this. All breakout boards have been redesigned and are in fab.