Home
JAQForum Ver 24.01
Log In or Join  
Active Topics
Local Time 01:57 17 Jul 2025 Privacy Policy
Jump to

Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.

Forum Index : Microcontroller and PC projects : Pin25 Help

     Page 1 of 2    
Author Message
jman

Guru

Joined: 12/06/2011
Location: New Zealand
Posts: 711
Posted: 01:52pm 02 May 2015
Copy link to clipboard 
Print this post

Hi
I have two different PCB's (completely different designs)and they both do the same weird thing and that is to reset the Micro Micromite MKII 4.6B

To test could somebody please try this and post the result here.
10k Resistor from pin 25 to 3.3V and 100nf cap from pin 25 to gnd

Now every time I ground pin 25 the Micro resets
If you keep pin 25 to ground and then check it in MMBasic to will show as low
and show as high when you remove the ground

The reset only happens when going to ground not when removing the ground

and the kicker if you remove the 100nf cap everything works as normal so why does the cap to gnd cause the Micro to reset ?

Confused
Jman

Edit Pin 26 and Pin 3 do NOT have this issue (those are the ones I tested with)
Edited by jman 2015-05-04
 
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9594
Posted: 03:29pm 02 May 2015
Copy link to clipboard 
Print this post

Standby.......

EDIT: My FIRST guess on this(without testing - hooking it up now), is that grounding pin 25 is effectively shorting out the charge held in the 100n cap between pin25 and ground(having been charged up via the 10k pull-up to 3v3), and this is causing a spike through pin25 and upsetting the core.

You could try a 1k in series with pin25 and your cap arrangement.

I will post back shortly.

EDIT: Unable to reproduce this, unfortunately. I have tried with the MM sitting at the console, and running in an infinite loop to see if it only affects a running program.

10k from 3v3 to pin25, 100n monoblock from pin25 to deck(ground).
Jumper wire from pin25, and touch other end to ground.

No resets.

How do you have pin25 configured?
I may well need to configure same as you to get get same resets as you....Edited by Grogster 2015-05-04
Smoke makes things work. When the smoke gets out, it stops!
 
srnet
Senior Member

Joined: 08/08/2014
Location: United Kingdom
Posts: 164
Posted: 08:13pm 02 May 2015
Copy link to clipboard 
Print this post

Pin 25 on the 28 pin or 44pin device ?
$50SAT is Silent but probably still working.
For information on LoRa visit http://www.loratracker.uk/

 
jman

Guru

Joined: 12/06/2011
Location: New Zealand
Posts: 711
Posted: 09:45pm 02 May 2015
Copy link to clipboard 
Print this post

  srnet said   Pin 25 on the 28 pin or 44pin device ?


28 pin

Jman
 
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9594
Posted: 10:46pm 02 May 2015
Copy link to clipboard 
Print this post

Pin25 configuration?
Smoke makes things work. When the smoke gets out, it stops!
 
jman

Guru

Joined: 12/06/2011
Location: New Zealand
Posts: 711
Posted: 11:39pm 02 May 2015
Copy link to clipboard 
Print this post

  Grogster said   Pin25 configuration?

SetPin 25, Din


But it seems to do it even with no MMBasic program loaded


Jman
 
paceman
Guru

Joined: 07/10/2011
Location: Australia
Posts: 1329
Posted: 01:58am 03 May 2015
Copy link to clipboard 
Print this post

Just tried your setup and V4.6B on my MX170 John - seems to be fine, no resets.
I used:

>
setpin 25,din
Do:x=pin(25):? x:pause 500:loop

and then just swapped the jumper back and forward from 3.3v to Gnd. It returned the 0's or 1's as expected.

GregEdited by paceman 2015-05-04
 
WhiteWizzard
Guru

Joined: 05/04/2013
Location: United Kingdom
Posts: 2934
Posted: 01:04am 05 May 2015
Copy link to clipboard 
Print this post

Everything fine here too after a quick test.

Two suggestions:

1> Not knowing what power supply you have - have you tried a different one to see if the same thing happens? Also, could you be close to the 'limits' of current availability? (possible if you have any other hardware components in place)

2> Check Vcap across pins 19&20 (i.e. vCap to GND). Try a different one if possible!

If both these fail to solve the issue then maybe the 'surge' in current has 'upset' the MicroMite (possibly permanently).

I would definitely add a series resistor into any digital input pin (usually use a 1K like Grogster has already mentioned).

These kind of problems can be difficult to trace - so what may seem like a strange suggestion could actually resolve your issue. So can I also suggest on this basis to reload the Firmware (assuming you have the ability/tools to do this). I once had strange behaviour from a MicroMite when I inadvertently put 5v into the PIC across various pins (and assumed it was damaged for good). However, I reloaded the firmware to see what would happen and once it was reloaded the MicroMite behaved as if it were new!!! (and has been running a clock for me in the bedroom ever since without any issues).

Keep us updated with your findings . . . .

WW
 
bigmik

Guru

Joined: 20/06/2011
Location: Australia
Posts: 2949
Posted: 01:19am 05 May 2015
Copy link to clipboard 
Print this post

Hi Jman,

I have just tested it using MuP and I get no resets or anything. In fact it appears to work perfectly, I toggled the GND madly with no problem.

If you are getting this occur on several setups I would suggest looking for the common denominator..

What HEX did you use? Is it corrupted? Get a fresh copy from Geoff's site and test that.

What capacitor did you put for VCap (across pins 19 and 20)?

Now the really stupid question that I have to ask.. Are you sure it is a 10k you used and not 10 Ohm or even 1 Ohm?


Regards,

Mick

Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<<
 
OA47

Guru

Joined: 11/04/2012
Location: Australia
Posts: 982
Posted: 05:58pm 05 May 2015
Copy link to clipboard 
Print this post

Jman, I had a similar issue some time back and it was caused by a very high frequency spike created during the transition from high to low. If the spike approached the 3V3 limit the mite would reset. I managed to use one of the 5V rated pins and all was good. Not sure of the internal circuitry of the pin 25 and the addition of your passive components but together they may create the same issue.

May not be your answer but who knows?
GM
 
jman

Guru

Joined: 12/06/2011
Location: New Zealand
Posts: 711
Posted: 09:15am 07 May 2015
Copy link to clipboard 
Print this post

  Graeme Meager said   Jman, I had a similar issue some time back and it was caused by a very high frequency spike created during the transition from high to low. If the spike approached the 3V3 limit the mite would reset. I managed to use one of the 5V rated pins and all was good. Not sure of the internal circuitry of the pin 25 and the addition of your passive components but together they may create the same issue.

May not be your answer but who knows?
GM


Thanks for the info at least I am not alone.
I will hook the DSO over the weekend and report back here

Regards
Jman
 
jman

Guru

Joined: 12/06/2011
Location: New Zealand
Posts: 711
Posted: 04:40pm 08 May 2015
Copy link to clipboard 
Print this post

Hi

After much mucking around (changed power source changed Vcap etc.....)
If I swop to pin26 the problem is solved (or remove the 100nf from pin 25)
I have swopped the function of 25 and pin 26 and all is now well

A quick look at the data sheet of MX170 shows the difference between pin 25 and pin 26 Pin 25 is also the CVREFOUT pin I don't know if this means anything maybe Geoff can tell us.

Pin 26 AN9/C3INA/RPB15/SCK2/CTED6/PMCS1/RB15
Pin 25 CVREFOUT/AN10/C3INB/RPB14/SCK1/CTED5/PMWR/RB14

Regards
Jman
 
Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3285
Posted: 02:21am 09 May 2015
Copy link to clipboard 
Print this post

No, there is no significant difference between the two pins and CVref is not used by MMBasic.
Geoff Graham - http://geoffg.net
 
robert.rozee
Guru

Joined: 31/12/2012
Location: New Zealand
Posts: 2437
Posted: 03:45am 09 May 2015
Copy link to clipboard 
Print this post

if you erase all your basic code from the micromite, does it still have the same problem. i am wondering if there is a sequence of commands that mis-configure the pin, and that your code is auto-running this sequence every time power is applied.

cheers,
rob :-)
 
jman

Guru

Joined: 12/06/2011
Location: New Zealand
Posts: 711
Posted: 10:05am 09 May 2015
Copy link to clipboard 
Print this post

  robert.rozee said   if you erase all your basic code from the micromite, does it still have the same problem. i am wondering if there is a sequence of commands that mis-configure the pin, and that your code is auto-running this sequence every time power is applied.

cheers,
rob :-)


Hi Rob

Yip tried that to and the problem is still there.
One thing I did notice is that if the 10K resistor is not mounted on the PCB
but mounted on the switch and connected to the Umite via a 20cm wire the problem is worse :(

Regards
Jman
 
bigmik

Guru

Joined: 20/06/2011
Location: Australia
Posts: 2949
Posted: 01:39pm 09 May 2015
Copy link to clipboard 
Print this post

Hi JMan,

I have tried it with a resistor and Cap soldered onto female headers plugged into MuP as well as 30cm wires onto (an infamous) bread-board, and cannot get it to trigger a reset (or power glitch as I suspect it actually is)..

Can you please offer more description as to the environment you have this in when you test it? I guess, from your fantastic recent post, that it must be in a car with some sort of power adapter from 12V to 5 or 3v3.. Also can you check the polarity and let us know what type of capacitor you are using on VCap (between pins 19 and 20 on a 28pin job) +ve (the bar on a tantalum) should go to pin 20. I know this sounds obvious and you are obviously well experienced with MicroMites etc, but its seems strange that no one else can duplicate your problem but you can very easilly duplicate and with several boards.

I reckon it has to be related to power supply or VCap. Can you run a test running it from a battery pack instead of an AC charger or car battery with its alternator noise, CAN-BUS communication `noise' etc.

Regards,

Mick
Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<<
 
WhiteWizzard
Guru

Joined: 05/04/2013
Location: United Kingdom
Posts: 2934
Posted: 08:32pm 09 May 2015
Copy link to clipboard 
Print this post

Even though you have fixed the issue by using pin26, I am sure there are many of us curious as to why you (and only you) still see the issue on Pin25

Is the MM in a socket? If so then isolate all pins except the 'basic' pins required for operation (and Pin 25).
Do this by removing the PIC, bending 'out' all pins apart from the required ones, and then re-inserting the PIC. So the only pins actually in the socket are : 1,8,13,19,20,27,28 and 25 - possibly 11 & 12 for console too if there are no other obvious ways of seeing the MM has reset!!

If you still see strange behaviour then it has to be an issue with power source and/or Vcap and/or a damaged PIC. And one other possibility; is it a software bug!

You mentioned it happens on two totally different designed boards so could you have been doing something else on Pin 25 that has caused both PICs to get 'damaged' on pin 25? i.e. too much current. A simple test would be to replace the PIC with a brand new one to ensure Pin25 is 'undamaged'.

You say you have tried different power sources - as BigMik says, are these 'away' from noise?

Regarding the Vcap - if you are using a tantalum then do check polarity. We recently had another member with a problem caused by a tantalum connected the wrong way round. My preference is to use a 10uF ceramic (never had a single issue in well over 200 MM modules).

So we're are left with software. Can you run the test software that was posted here by another member (on Page 1 so I can't get to see who it was while typing this post!). This will eliminate any 'oversight' whereby you may have Pin25 left in a 'high' state and hence when you ground it then it results in a Reset. For example - if you are using SPI elsewhere within your code, then Pin 25 (being the SPI clk) could go high which may result in a Reset when grounded.

The only way it seems we will get to 'solve' this strange issue is by isolation and going back to basics. I am sure you have tried most of what I have said - so this is more of a 'sense' check - but who knows, it may include something that hasn't yet been 'tested'.

WW



Edited by WhiteWizzard 2015-05-11
 
robert.rozee
Guru

Joined: 31/12/2012
Location: New Zealand
Posts: 2437
Posted: 05:08pm 12 May 2015
Copy link to clipboard 
Print this post

john: when the micromite resets, is the stored program erased? worth checking to ensure this isn't related to the 'unintended erasure' issue discussed elsewhere.

also, have you seen the behaviour with more than one MX170? if needsbe i've got a few MX170's here that you can try - can't remember if you have a pickit or similar for programming the devices yourself.

P.M. me if you'd like a hand sorting out the mystery.


cheers,
rob :-)
 
jman

Guru

Joined: 12/06/2011
Location: New Zealand
Posts: 711
Posted: 10:49pm 12 May 2015
Copy link to clipboard 
Print this post

Hi Robert

Nope program remains. Yip I have a PICKIT 3

PM sent

Jman
 
robert.rozee
Guru

Joined: 31/12/2012
Location: New Zealand
Posts: 2437
Posted: 08:55pm 15 May 2015
Copy link to clipboard 
Print this post

i popped over to see john (jman) this afternoon and have been able to confirm the reported behaviour with my own eyes. we tested with both an MX150 and an MX170, various versions of micromite basic AND also with an MX150 that was not running MMbasic but instead a short "flashing LED" test firmware that geoff kindly supplied me a while back when i was testing out programming PICs with pic32prog. different firmwares were loaded using a pickit2 and pic32prog.


the hardware setup was as follows:

- PIC32 wired up as per the micromite basic manual. connected to a PC (in my case a netbook) using a CP2102 USB to serial bridge. i used the 3v3 output from the USB bridge to power the PIC32. very solid connection between all 3 ground pins, correct Vcore capacitor, 0.1uF filter capacitor across supply at PIC.

- a 0.1uF ceramic capacitor wired between pins 25 and 27 extremely close to the PIC32 body. in my case i had the PIC32 in a ZIF socket, and the 0.1uF capacitor clamped into the socket next to the PIXC32. john had his one soldered across the pins at the back of the machined-pin socket holding the PIC32.

- a switch (push button) and 10k resistor at the end of 3 flying leads approximately 6" long, switch and resistor in series, junction to pin 25, bottom end of switch to pin 27, and top end of resistor to pin 28.

- the resistor provided a pullup to 3v3, while the switch shorted out the 0.1uF capacitor when closed.


when running MMbasic and sitting at the command prompt, closing the switch would cause the PIC32 to reset and MMbasic to print out the welcome message. this occured upon closure of the switch, and would happen on perhaps 95% of switch closures. it never happened on switch opening.

if the supply an ground for the switch/resistor was taken from pins 13 and 8 instead of 28 ans 27, resets appeared to occur less frequently, but still did occur sporadically.

if a program was running, it would be interrupted when the reset occurred. on the occasions there was no reset the program would continue OK. one such test program:

setpin 25, din
start:
print pin(25)
goto start


if geoff's "flashing LED" firmware was loaded, which slowly flashed an LED attached to the console TxD line, then closing the switch would cause a reset that interrupted the interval of the 'current flash'. note that this is without the micromite firmware loaded onto the PIC32.


it appears there are two likely culprits:

1. the compiler (and associated libraries) used to generate both micromite basic and "flashing LED" briefly configures pin 25 as an output "1" when the switch is closed. driving into the dead

2. a silicon error on the MX150 and MX170 causing the attempt to pull pin 25 high.


the behaviour observed is very repeatable provided the 0.1uF capacitor is wired extremely close to pins 25 and 27. it is enhanced by having the supply and ground to the switch taken from pins 28 and 27. in all cases the switch and resistor were suspended on 3 flying leads approximately 6" long.


cheers,
rob :-)
 
     Page 1 of 2    
Print this page
The Back Shed's forum code is written, and hosted, in Australia.
© JAQ Software 2025