It’s all part of the fun…just sucks that I was confident enough to buy a large batch of boards. 
5 Likes
I’m heading out. I will check the emails later but bypassing that chip is an easy test. Who knows maybe I screwed up something else on accident. The rest of the board with no pendant plugged in works perfect as much as I have tested at least.
2 Likes
so right now, the only problem is the pendant cannot be ON during boot, right? So put a switch on the pendant somewhere until we figure this out! There is a positive feed coming through the umbilical right?
bahaha, i just re-read this, (we, like i can help 
)
The pendant gets its power from the jackpot, and should be able to be plugged in on boot. As much as a bandaid would fix this, there is a bigger problem that has to be found.
2 Likes
I was just trying to get those boards used, that is all
1 Like
Crap.
That sounds like either a conflict with flash, a weird initial state for those GPIOs or the protection stuff is the problem.
Not good. I wonder how much current is being drawn. Get an IR picture? Do the protection parts get hot?
Damn.
Ok here’s some suggestions:
Grab some side cutters or a pair of hot tweezers and pull the protection parts off one board. Re-test.
Make a pigtail, pull out GND, 5V, and the two GPIOs you aren’t using for the on-jackpot RJ12.
Connect this up to a pendant, change your confi.yaml, try to boot up with that configuration.
Do the latest revs have protection on just the RJ 12 or also on the other 2 GPIOs on the expansion header?
2 Likes
Yeah I tried to see if either of the two pins could be a boot problem. “boot fails if pulled high, strapping pin” pin 12…so maybe 12 is getting pulled high, not sure if that is easily solved with a pull down resistor without messing up the uart signals, I assume so. I can put the scope on it and see what happens vs the boards enable pin in terms of timing. I guess I can even bodge up some pull downs, I think there is a spot.
15, also says it is a strapping pin but no warnings.
The board sits at 24v 0.6A with the steppers holding, with the pendant in at boot it hits 1.2A and holds.
I think I can pull off that chip and just jump the two signal pins, and also the 5v. That shoudl rule out the chip itself I hope. I am getting a little better with the hot air so I can probably even put it back if I am lucky,.
Good idea, to check the pendant itself. I will try this third if the other two are not obvious issues.
Just the rj12
Awwww man
- GPIO 12 (must be LOW during boot)
- GPIO 15 (must be HIGH during boot)
Guess what two pins we are using. I am not seeing how this would not be an issue with the header on the JP1 and the pendant unless you all were using the other two pins. I need to check into that. Seems like a potential header issue that needed to be fixed either way.
I don’t think so I poked around quickly. I am fairly sure it is just the 5v section. Good idea to take a picture.
1 Like
So how many is a large batch?
1 Like
So what are they now?
1 Like
Yeah. This is weird. Remind me/ did we swizzle the GPIOs for the V2 vs V1 expansion header?
If so, I can’t recall why.
That’s outrageous !
No way the pendant can be pulling 14 watts all by itself.
Is the ESP-32 getting toasty too?
2 Likes
Drawing more current is an interesting one. That’s very strange and sounds like it might be a pin getting stuck in an output state and fighting another one.
That’s not uncommon, the 3.3V may not be at 3.3V and there’s usually a small impedance or voltage drop on the outputs. Worth bearing in mind and checking, but not surprising.
That’s worth doing. Given that layout, it’s probably worth linking pins 1-6 and 3-4 with a trace for future versions. Even though they’re connected internally, I’d link them which will give you the option of just pulling the chip in the future if it gets damaged. Alternatively you could add external 0R resistors but given the behaviour of that circuit I would just link it.
It’s worth doing but it seems weird that everything works post boot… If it was that chip being wired wrong or something I’d expect it to be always faulty, not just at boot. Given that you’ve got the 120R resistors there, you can look at the voltage on either side of them during boot and see if there’s a significant amount of current through them. That’d indicate that there are GPIO in the output state and fighting each other. You can do that by just looking at both directly on the scope or by using a math channel to look at A - B.
Not at all and I really appreciate the heads up. I’d rather see something earlier and be able to respond rather than come into it 400 posts later and have to cover ground that people may have already addressed etc.
True, but that’s how you narrow down the symptoms to a root cause. I think the idea would be to separately boot the pendant first maybe, or supply it with a separate 5V power and see what happens.
That’s a good way to check and see what’s going weird. How much is ‘twice as much current’? An extra 10mA? Extra 200mA? The delta is probably more important than the absolute.
Ah balls, that’s a LOT of extra current… And that’s drawing 24V at 1.2A or is the power supply current limiting and folding back? I assume this is off a bench power supply? That’s an apocalyptic amount of extra power going somewhere.
So most likely your issue will be the pin that’s acting as a receive. I’d start with that one. You also may not be able to adequately add a pull-down or pull-up unless the other end is in High-Z else it’ll just drive the output. This can be solved in a few ways doing stuff like adding buffers or analog switches but it gets ‘interesting’. A better approach would be to try use those pins as outputs for things that can always safely be pulled to idle at the right levels.
2 Likes
So assuming it’s the bootstrapping that’s the issue, let’s work through the logic here.
It looks to me like currently you’ve got GPIO15 as an output (tx) and GPIO12 as in input (rx), assuming those labels are relative to the main controller.
GPIO 15, the output, needs to be high at startup and GPIO 12 needs to be low. The output is easy to deal with because you just put a pull-down or pull-up in the right direction. The input is harder because it’s externally driven and you probably want to be able to boot reliably, regardless of whether it’s a cold boot (newly applied power) or a warm boot (reboot due to software reset, crash etc.).
Regardless, I would add pull-ups and pull-downs to keep them in the correct state in case the other end is high-Z.
A slightly hack way to approach this is that a TTL UART idles high, so if the protocol that’s used to talk to the dial doesn’t respond unless it receives something, you could swap Tx and Rx. That way the ‘idle’ state from a booted dial would be the correct bootstrap state for that pin on the controller.
The ‘proper’ way to do this (aside from avoiding bootstrap pins like the plague) is to make sure that all bootstrap pins are outputs from the controller and can be pulled in the right direction, or that they’re isolated by something like a buffer or analog switch that can be separately controlled by an enable line. Ideally that enable would be something else controllable by the micro that idles in the disabled state and then is enabled during the boot process once code is running. Alternatively you can take the state of other lines and do stuff with those, such as if you know that the UART will always be talking constantly once booted, you can use the UART going out of idle (i.e. going low) to enable the circuit and then use a peak-detect type circuit so that the UART must be idle for a period of time before it goes back to disabled. That kinda thing.
Alternatively, you could also adjust the software in the dial such that it doesn’t enable the output until it needs to talk and leaves it high-Z at other times, or falls back to high-Z if it doesn’t hear from the controller for a period, etc. There are a ton of approaches possible, it’s just figuring out which one works for all the scenarios considered… Good old systems integration.
First things first, though, which is probably verifying that it’s a bootstrapping issue.
3 Likes
Interesting - this is same behaviour I’m seeing with my uart bridge on the current jackpot. I tried 100mf decoupling caps and a setup delay on the bridge board to no avail so watching with interest…
2 Likes
@jono035 if the problem is pin 12 and 15 this would not fix (bandaid) the problem though would it? If external power it would still enact the gpio pins and cause the problem?
Okay so pin 12 without the pendant plugged in is low at boot, then goes high.
With the pendant plugged in pin 12 is at 2.3v during boot then goes high to 3.3v.
So we need to add a pull down to 12. lemme try that real quick.
It is kinda good to catch this here instead of the module header.
Are you using pin 12?
1 Like
That must be the TMC drivers acting on their own without getting any information from the esp about what settings to use. I bet if you disconnected the motors, that would be the real number for just the electronics.
Actually, those TMC drivers do have default settings controlled by pins. I wonder if that is any different in v2 vs the standalone tmc daughter boards.
1 Like
Yes, 12 and 15
Okay, sorry I got stuck on a phone call.
10k pulldown on pin12 was not enough, it would work with the probes on but not without them so it was right on the edge.
A 5k pulldown works perfectly
I can’t find a USB stick to share scope screenshots but pin 12 still has a little bit of voltage on it at boot, under 1v. I could go with a 1k pull down. pendant works fine, not sure how to test if the signal is getting messed with or anything.
That a 5k resistor from pin 12 to ground.