I have a lidar rangefinder (Benewake TF03 LIDAR LED Rangefinder IP67 (100 m) - RobotShop) connected to the P2 module on Serial 1. The module is unpowered on bootup; the 5v supply for the module is controlled by a GPIO on the P2. There is a weak external pull up (10k) on the TX pin, as mentioned in the datasheet.
Apparently this pullup is not enough, and if the rangefinder is plugged in, the P2 will not boot up and appears to be in this “ISP Download” mode; there is lots of data activity on that pin.
I am able to get it working by putting a fat 1k pullup on that TX pin, as well as the RX pin, but even then I see some intermittent times where it enters ISP download mode.
I’m unclear how much of this behavior is caused by the module itself (sounds like theres a path internal to the device from RX to ground which is pulling the pin low enough on boot?)
Can any insight to this ISP Flash Download mode’s intention and behavior be expanded on? What is it’s purpose, and are there any more detailed best hardware practices I should follow to prevent accidently entry into this mode?
I feel like this might be a problem for others as well if having serial devices connected to Serial1 prevents the device from booting.
1 Like
Yes, the TX pin is a special pin that will enter MCU reprogramming mode (ISP download) if it goes low at boot. Since most users use the TX pin as an OUTPUT, you would not run into this normally.
Data on the RX pin should not be triggering ISP download mode even if there is RX data at boot time. It would be interesting to see oscilloscope/logic analyzer data on both TX and RX during the boot process to see if there’s actually voltage on the TX line, though that still will not indicate exactly why.
Do you have pins available for the other UART ports? There are Serial2 and Serial3 on the P2. That could be an option. Adding a buffer with output enable or a gate to stop the RX data might be an option.
I do suspect the issue being that the serial device itself causing the issue; if I probe the devices RX pin to ground with it powered off, it’s at 4k ohm, which will pull that line low unless overcome with a bigger pullup.
On my device, all serial ports are used up, so there’s no open port to move them too. It’s possible that the other serial devices might not have the same pulldown, so maybe I could just switch devices around until it works.
While swapping, buffers, or fets are certainly options for me, I just wanted to note that it might be something the eventual users of the Photon 2 board might have issues with; they’ll likely just plug serial devices into the serial port, and knowledge of how that device behaves relative to pull up/down of the TX pin will be secondary only after it prevents their module from booting.
I’ll grab a scope trace of both TX/RX tomorrow.
Scope traces!
For reference, heres a normal, successful boot with the device disconnected.
Here’s the failure; a serial based rangefinder module that is unpowered, but appears to have a pull-downs to ground inside of the device of around 4kohm
Looks like this isn’t surprising then, P2 TX (the magic pin) is at ~2v on boot, which is probably riiiight on the cusp of a TTL level, and the P2 enters ISP download mode.
So I guess this means nothing is wrong! The P2 is doing what it says on the datasheet. I’ll implement some kind of buffer or low side switch on the device.
My only comment is that I won’t be the last person who connects a device to the TX/RX port, and depending on the device, behavior will be indeterminate, which isn’t terribly user friendly. It would be cool if there was some other gate on the ISP mode, like the MODE switch needs to be low as well on boot or something. I understand that things are sometimes set in stone at this low level hardware boot things, so something like this will probably not be feasable.
Thanks for letting me rant!
1 Like
Thank you for the testing!
Unfortunately ISP download is a really low-level feature, before our bootloader code executes, so we can’t trap it. The only option would be to use a different pin, but because the RTL872x generally hardcodes pin functions to hardware pins, unlike the nRF52, which has a big MUX in front of many of the pins, there are only so many serial pins. And since the other serial pins are also used as GPIO, that’s generally a worse choice for the ISP download boot pin, because it would be even more likely that someone would hold it low at boot.
Still not ideal, and certainly annoying for you, but that’s how it came to be.
1 Like
Thank you @willdueease!
This has been an ongoing problem on our boards but I had wrongly assumed a power supply issue. We'll need to add a pull-up.
Hopefully Particle can document this on the pin description in their P2 datasheet and Argon migration guide along with recommendations.
