Jump to content



Photo
- - - - -

Preview release: Pinscape Pico


  • Please log in to reply
150 replies to this topic

#41 DDH69

DDH69

    Pinball Wizard

  • Platinum Supporter
  • 3,502 posts
  • Location:DOFLinx HQ, Adelaide

  • Flag: Australia

  • Favorite Pinball: Monster Bash

Posted 19 February 2025 - 02:50 AM

>> Give it a try and if that helps.

 

No change


DOFLinx
Contributions for equipment to help with ongoing DOFLinx development can be made here

#42 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,260 posts

  • Flag: United States of America

  • Favorite Pinball: Medieval Madness

Posted 19 February 2025 - 03:11 AM

Well, I’m out of ideas for now, then… let me know if you find anything new.



#43 DDH69

DDH69

    Pinball Wizard

  • Platinum Supporter
  • 3,502 posts
  • Location:DOFLinx HQ, Adelaide

  • Flag: Australia

  • Favorite Pinball: Monster Bash

Posted 19 February 2025 - 03:21 AM

Well, I’m out of ideas for now, then… let me know if you find anything new.

 

I have rebuilt both 1 and 2 chip circuits on my push in experimentation board with the same results.  I'm convinced there is a config or coding issue, not hardware.  To help me try the config angle, is it possible to get a config file that works for you with >=2 chips.  I can then load another Pico and see if I get the same result as you.


DOFLinx
Contributions for equipment to help with ongoing DOFLinx development can be made here

#44 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,260 posts

  • Flag: United States of America

  • Favorite Pinball: Medieval Madness

Posted 19 February 2025 - 03:32 AM

The config is so simple that it seems unlikely to be the problem - if anything were wrong there, I'd expect it just not to work at all.  But here's what I'm using:

	// 74HC165 input shift register
	"74hc165": {
		nChips: 4,
		data: 9,
		shift: 7,
		load: 8,
	},

What's exact chip manufacturer and type you're using?



#45 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,260 posts

  • Flag: United States of America

  • Favorite Pinball: Medieval Madness

Posted 19 February 2025 - 03:49 AM

Another debugging tool you should try.  Make sure you have a console configured on USB CDC:

serialPorts: {
    usb: {
        console: { enable: true },
    },
},

That'll create a COM port that you can connect to via a PuTTY window (or any other terminal emulator).  The COM port number will be displayed on the Device Overview page in the config tool.  Open up PuTTY and type:

 

74hc165 -s

 

That'll show you some stats, including the raw bit stream that it's reading from the device.  Ground port A on chip 0 and see what the bit stream looks like.

 

It'd be great to try that with your test setup with one physical chip installed and nChips:4 config setting, to see what the data stream looks like in that case.  And maybe try nChips:2 as well (one physical chip again) for comparison.


Edited by mjr, 19 February 2025 - 04:12 AM.


#46 DDH69

DDH69

    Pinball Wizard

  • Platinum Supporter
  • 3,502 posts
  • Location:DOFLinx HQ, Adelaide

  • Flag: Australia

  • Favorite Pinball: Monster Bash

Posted 19 February 2025 - 04:17 AM

Unwrapped a new Pico, loaded firmware, loaded the "Starter" config, added the config you have (as per above), same result.

 

>> What's exact chip manufacturer and type you're using?

The markings are

21AJVNM G4  (the G4 is underlined)

SN74HC165N

source = https://www.jaycar.c...ter-ic/p/ZC4858

 

>> 74hc165 -s

 

No inputs FF FF FF FF

Chip 0/A FF FF FF FE

Chip 1/A FE FF FF FF

Chip 2/A FF FE FF FF

Chip 3/A FF FF FE FF


DOFLinx
Contributions for equipment to help with ongoing DOFLinx development can be made here

#47 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,260 posts

  • Flag: United States of America

  • Favorite Pinball: Medieval Madness

Posted 19 February 2025 - 05:17 AM

Seems like the genuine TI chip, at least they link the data sheet for it.  Did you try the one physical chip installed test?  That’s the one I really want to see, with the different nChips settings.  Having only one chip connected at least reduces the number of variables to control.



#48 DDH69

DDH69

    Pinball Wizard

  • Platinum Supporter
  • 3,502 posts
  • Location:DOFLinx HQ, Adelaide

  • Flag: Australia

  • Favorite Pinball: Monster Bash

Posted 19 February 2025 - 06:05 AM

>> Did you try the one physical chip installed test?

 

Sorry missed that test in the middle there.  Done now, here are the results;

 

1 physical, nChips = 4 with "A" button on chip 0 => 00 00 00 FE

1 physical, nChips = 3 with "A" button on chip 0 => 00 00 FE

1 physical, nChips = 2 with "A" button on chip 0 => 00 FE

1 physical, nChips = 1 with "A" button on chip 0 => FE ---> REPORTS CORRECTLY

 

In addition ......

2 physical, nChips = 1 with "A" button on chip 0 => FE ---> REPORTS CORRECTLY

2 physical, nChips = 2 with "A" button on chip 0 => FF FE

2 physical, nChips = 2 with "A" button on chip 1 => FE FF

 

Only with nChips=1 is the correct result obtained.


DOFLinx
Contributions for equipment to help with ongoing DOFLinx development can be made here

#49 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,260 posts

  • Flag: United States of America

  • Favorite Pinball: Medieval Madness

Posted 19 February 2025 - 06:33 AM

One more dumb question: all ports are pulled up to 3.3V, right?



#50 DDH69

DDH69

    Pinball Wizard

  • Platinum Supporter
  • 3,502 posts
  • Location:DOFLinx HQ, Adelaide

  • Flag: Australia

  • Favorite Pinball: Monster Bash

Posted 19 February 2025 - 06:38 AM

>> One more dumb question: all ports are pulled up to 3.3V, right?

 

Yes, a 10k resistor to +3.3V.  Button on pulls the pin to GND.


DOFLinx
Contributions for equipment to help with ongoing DOFLinx development can be made here

#51 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,260 posts

  • Flag: United States of America

  • Favorite Pinball: Medieval Madness

Posted 19 February 2025 - 06:57 AM

Great, exactly right.

 

I added some more diagnostics you can try:

 

http://mjrnet.org/pi...g-20250218b.zip

 

Console mode again:

 

  74hc165 --dma-off

  74hc165 --bitbang

 

You can repeat the --bitbang a few times with 0A pressed and not pressed to compare.  --dma-on to resume normal operation.  This will do a direct read of the chip ports, to see if this gets the same result as the PIO reader.  The same series of tests with one physical chip would probably be good to try, and maybe even the two or four physical chip case.



#52 DDH69

DDH69

    Pinball Wizard

  • Platinum Supporter
  • 3,502 posts
  • Location:DOFLinx HQ, Adelaide

  • Flag: Australia

  • Favorite Pinball: Monster Bash

Posted 19 February 2025 - 08:43 AM

Now this just got interesting!  Please excuse the CAPS, just meant to draw attention to comments.

 

1 physical, nChips:1

- no buttons dma = FF

- 0A dma = FE

- no buttons bitbang = FF

- 0A bitbang = FE

 

1 physical, nChips:2

- no buttons dma = FF 00  (NOTE THIS IS REVERSED FROM PREVIOUS TESTING AND GAVE CORRECT BUTTONS IN SOFTWARE ! )

- 0A dma = FF 00

- no buttons bitbang = FF 00

- 0A bitbang = FE 00

 

2 physical, nChips:2  ( AGAIN WORKING AS EXPECTED WITH CORRECT KEYS FOR THE FIRST TIME )

- 0A dma = FE FF

- 1A dma = FF FE

- 0A bitbang = FE FF

- 1A bitbang = FF FE

 

2 physical, nChips:3  ------------------------- NOW THIS ONE GETS INTERESTING, DMA and BITBANG ARE DIFFERENT.  NO UNPLUG OR RESET BETWEEN TESTING.

- nothing pressed, dma = FF 00 FF

- 0A  dma = FF 00 FE

- 1A dma =  FE 00 FF

- nothing pressed bitbang = FF FF 00

- 0A bitbang =  FE FF 00

- 1A bitbang =  FF FE 00

 

4 physical, nChips:4  -------------------- AGAIN DMA AND BITBANG RETURN DIFFERENT RESULTS. UNIT REMAINED PLUGGED IN WITHOUT RESET OR ANY OTHER CHANGES

- nothing pressed dma = FF FF FF FF

- 0A dma = FF FF FF FE

- 1A dma = FE FF FF FF

- 2A dma = FF FE FF FF

- 3A dma = FF FF FE FF

- 0A bitbang = FE FF FF FF

- 1A bitbang = FF FE FF FF

- 2A bitbang = FF FF FE FF

- 3A bitbang = FF FF FF FE

- note, simply turning --dma-on and retesting with -s after the --bitbang got the same incorrect dma results


Edited by DDH69, 19 February 2025 - 08:44 AM.

DOFLinx
Contributions for equipment to help with ongoing DOFLinx development can be made here

#53 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,260 posts

  • Flag: United States of America

  • Favorite Pinball: Medieval Madness

Posted 19 February 2025 - 07:47 PM

DDH69 - another firmware test build for you to try.  This one adds a "74hc165 --dma-once" console diagnostic test, to run the PIO DMA cycle one time in the foreground.  Needs --dma-off mode (like --bitbang).

 

Separately, I identified a logic error that might be the underlying cause.  It's definitely an error, but I haven't been able to construct in my mind the precise path for how it gets to the symptom you're seeing, and more precisely, why it causes that symptom in your setup and not mine.  So there might be another factor still to be found.  Hopefully the --dma-once test will provide more data if so.

 

http://mjrnet.org/pi...g-20250219a.zip



#54 DDH69

DDH69

    Pinball Wizard

  • Platinum Supporter
  • 3,502 posts
  • Location:DOFLinx HQ, Adelaide

  • Flag: Australia

  • Favorite Pinball: Monster Bash

Posted 19 February 2025 - 09:20 PM

Well that fixed it!

 

Do you want me to test -dma-once still?  Happy to do so if it add information to the knowledge pool.


DOFLinx
Contributions for equipment to help with ongoing DOFLinx development can be made here

#55 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,260 posts

  • Flag: United States of America

  • Favorite Pinball: Medieval Madness

Posted 19 February 2025 - 09:39 PM

> Well that fixed it!
 
Wonderful!  I still can't work out exactly what was different between our two systems that made the behavior so different, but the bug fixed in this latest patch was a definite error in the DMA transfer setup, so it seems likely that it was the true root cause, given that it finally works right on your system.
 
> Do you want me to test -dma-once still?  Happy to do so if it add information to the knowledge pool.
 
Not necessary - we can go back to that if it starts acting up again.


#56 DDH69

DDH69

    Pinball Wizard

  • Platinum Supporter
  • 3,502 posts
  • Location:DOFLinx HQ, Adelaide

  • Flag: Australia

  • Favorite Pinball: Monster Bash

Posted 19 February 2025 - 09:51 PM

Thank you, onto the next part of the build now.


DOFLinx
Contributions for equipment to help with ongoing DOFLinx development can be made here

#57 DDH69

DDH69

    Pinball Wizard

  • Platinum Supporter
  • 3,502 posts
  • Location:DOFLinx HQ, Adelaide

  • Flag: Australia

  • Favorite Pinball: Monster Bash

Posted 20 February 2025 - 11:47 PM

Thought I'd "close the loop" on my experience with the MOSFET booster circuit.  Its taken me a while as been many years since I did my Electronic Engineering degree and there were a few things I needed to read up on.

 

>> You mean UCC27524P, right?  I don't think there is such a chip as UC2752P, but if there is and you're using that, that might be the problem.

 

Yes, my bad. My fingers clearly didn't want to type the full number.  The one part I couldn't order locally so came direct from Mouser via DHL.

 

I am using an IRF540N N-Channel MOSFET

 

A couple more UCC27524P's died in pursuit of experimentation for this one!  Anything under 150R for R6 and R7 ultimately resulted in the destruction of the chip.  They seem to be OK until you run them on a higher duty cycle, ie setup as digital out or PWM > 240 out of 255.

 

I did note on the specification sheet under Absolute Maximum Ratings that while rated to 5A, that is for 0.5uS whereas the I OUT_DC (output continuous source / sink current) is 0.3A Max.  I suspect this may be the item being exceeded with the lower R6/R7.  Having said that the numbers don't quite stack up using a simple Ohms Law calculation, but the real-life experimentation doesn't lie.

 

So from my experimenter board tests I have now built my first 6 digital channels on circuit board with the UCC27524P and IRF540N using 620R.  This is working reliably as both digital and PWM outputs.  I will be building another 16 PWM outputs on a second board soon.  I do note the points made by mjr about switching speed and heat, but ultimately I'm not running more than about 5A on these circuits, so not a huge concern for me.

 

As I said at the beginning, too many years since I did this for a living, but wanted to report my findings to hopefully make it a little easier for those who follow.


DOFLinx
Contributions for equipment to help with ongoing DOFLinx development can be made here

#58 DDH69

DDH69

    Pinball Wizard

  • Platinum Supporter
  • 3,502 posts
  • Location:DOFLinx HQ, Adelaide

  • Flag: Australia

  • Favorite Pinball: Monster Bash

Posted 21 February 2025 - 01:06 AM

@mjr, FYI the GUIConfigTool will crash and exit with no visible error message when you select either the "Log" or "Configuration" tab if you have an older version of the Microsoft Visual C++ Redistributable.  I simply updated to the latest and the problem was solved.  I still have one machine with the issue if you wanted any further information.  I have attached a copy of the error in Event Viewer for your information.

Attached File  GUICrash.png   44.53KB   3 downloads


DOFLinx
Contributions for equipment to help with ongoing DOFLinx development can be made here

#59 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,260 posts

  • Flag: United States of America

  • Favorite Pinball: Medieval Madness

Posted 21 February 2025 - 06:06 AM

> FYI the GUIConfigTool will crash and exit with no visible error message when you select

> either the "Log" or "Configuration" tab if you have an older version of the Microsoft

> Visual C++ Redistributable. 

 

Thanks - I didn't think I had any dependencies on that, but evidently the Scintilla DLL uses that (as it's invoked in those windows). I'll have to see if I can rebuild Scintilla without the dependency.  At least we know the fix now if anyone else runs into it.


... Yep, sure enough, it's configured to use the DLL.  I'll expunge that from the build.



#60 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,260 posts

  • Flag: United States of America

  • Favorite Pinball: Medieval Madness

Posted 21 February 2025 - 08:09 AM

> Thought I'd "close the loop" on my experience with the MOSFET booster circuit.

 

Great - thanks for the follow-up, I was hoping to hear more about it and see if I needed to revisit the circuit plan. Sorry you lost some chips in the process!

 

> Having said that the numbers don't quite stack up using a simple Ohms Law calculation,

> but the real-life experimentation doesn't lie.

 

Indeed, experimentation has a ruthless tendency to take into account all of the details one misses or hand-waves away when doing it on paper.

 

But I'd really like to figure out what I'm missing in the analysis.  Let me go through my thinking in a little more detail, see if you have any insights about what I'm getting wrong.

 

> I did note on the specification sheet under Absolute Maximum Ratings that while rated to 5A,

> that is for 0.5uS whereas the I OUT_DC (output continuous source / sink current) is 0.3A Max. 

 

Quite so.  BUT!  This is a MOSFET gate we're talking about:

 

gate-charging.jpg

 

Sorry for the crude hand sketch, but what I'm trying to show is a test circuit that measures the steady-state current from the 12V supply into the gate - the DC continuous output source/sink current from the data sheet, with the 300mA absolute maximum.  "A" is the ammeter.  If we turn the power on and leave it on, what will the ammeter read?  It's not an Ohm's law thing where we're going to read 12V/1R = 1A.  It's a MOSFET gate, so we're going to see a nice round 0 on the ammeter.  A little blip when we first apply power, but then 0 for as long as we leave it on.

 

More dynamically, the current is going to follow a curve like this when you first turn on the power:

 

gate-steady-state.jpg

 

When voltage is initially applied, current flows as fast as the gate resistor allows it to.  But the current just goes into charging up the gate, so as charge accumulates on the gate, the current slows down on an exponential decay curve, ultimately flatlining at zero once the gate is fully charged.  I'm oversimplifying - there's that whole Miller plateau business - but to a first approximation, you get a brief surge of current, quickly tapering off to zero as the gate charges.

 

There's a corresponding negative current surge when the power turns off, because the gate driver chip is deliberately designed to short the gate straight to ground when the drive turns off, to discharge the gate as fast as it charged the gate on the way in.  So for PWM drive, it looks like:

 

duty-cycle-50.jpg

 

So the implication seems to be that these pulses at the PWM switching points are exceeding the 0.5us allowance we have 

 

> They seem to be OK until you run them on a higher duty cycle, ie setup as digital out or PWM > 240 out of 255.

 

That does make some sense to me - and there should be a corresponding danger zone at the low end.  It's not the 255 that's the problem, it's the ALMOST 255, and correspondingly, ALMOST 0.  Those ought to be the zones of maximum danger exactly because of the surge of current at the ON and OFF edges of the input signal.  When the PWM cycle is ALMOST 100%, it spends almost the whole PWM period ON, turns OFF briefly near the end of the period, and then turns right back ON.  So you get a gate discharge interval leading straight into a gate charge interval, back to back, without any break in between for the poor driver chip:

 

duty-cycle-100.jpg

 

And the mirror image for duty cycle near 0%: you get a charge interval leading straight into a discharge interval:

 

duty-cycle-0.jpg

 

The negative discharge current places the same power dissipation demands on the driver chip as the positive charge current, so having them back to back essentially doubles the "pulse" interval.

 

> I am using an IRF540N N-Channel MOSFET

 

That's probably the difference between our test setups that made me think 4.7R was safe.  I'm using BUK7K89-100E.  Comparing data sheets, IRF540N has a much higher gate charge than BUKetc, so the time spent in the high-current charging/discharging zone is going to be correspondingly longer.

 

To an extremely rough first approximation, the high-current pulse time is Q[gd]/I, where I is the current.  That should be fairly ohmic during the Miller region, at (V[supply] - V[G][th])/R[g].  For your chip, V[G][th] is about 4V and Q[gd] is 13nC, so with 12V supply and 4.7R, we get I=1.7A, and pulse time 7.6ns.  That's still a tiny fraction of the 0.5us allowance in the data sheet..  But it's higher than my BUKetc, where I get 2.8ns by the same method.   For the "almost 0%" and "almost 100%" PWM scenarios we've been talking about, we can double those to 15.2ns and 5.6ns - but still way less than 500ns.

 

Are you running PWM at 20 kHz?  That's a 50us period, so that's eons for the chip to cool off between cycles.  Huh, I still do not get it.  15.2ns of current over 50us is only 0.03% duty cycle. I was expecting to arrive at a realization here that the pulse time was saturating the PWM cycle, giving the driver chip too little time to cool off between pulses.  But unless you've running your PWM in the MHz range, that doesn't seem to be it either.

 

I'm going to have to go back the data sheet and see what I can find.  Do let me know if you see any errors in my math.

 

At any rate, your finding that 150R is the cutoff point for safe operation is a good empirical result.  That limits the pulse current to 80mA, which is well within the 0.3A DC allowance.  I don't suppose you have an oscilloscope you can hook up to see what the actual empirical charge/discharge times are like for the 620R you settled on?  Back-of-the-envelope (same calculations as above) say that should give you about 1us turn on/turn off times, which is still only 4% (total) of the 50us PWM period at 20 kHz.  I.e., the MOSFET is only going to spend 4% of its time in the region where it tends to heat up.  That's easy enough to empirically test as well, just hook up a big motor or something and run it at various PWM levels to see if the MOSFET gets hot.  


Edited by mjr, 21 February 2025 - 08:19 AM.