​ ​ ​ ​ Comm issue with 14M2 chip
Page 1 of 3 1 2 3 LastLast
Results 1 to 10 of 26

Thread: Comm issue with 14M2 chip

  1. #1
    Member
    Join Date
    Jan 2010
    Location
    Australia
    Posts
    96

    Default Comm issue with 14M2 chip

    Hi all,
    I have one specific 14M2 that requires a hard reset, almost every time I commence an upload to it. If I just hit program, it come up with a comm port error, 8 of 10 times.
    I thought it may have been the cable interface or the drivers. But I have checked all that over and its all good. Besides, my other picaxe's have no issue with the hardware.

    This chip also went from working last night. To having no outputs driving at all this morning
    So I cleared the chip and tried again...and still nothing. Then I loaded a simple output test program....and all the outputs worked again
    So I then loaded the program that it was running again, and it is working as it should now.

    What I'm asking, has anyone else encountered this before? I don't want it messing up when I need it to work in this application.
    I could just change the Picaxe chip, but its SMD and a pain to get to. So I want to rule out every possibility first.

    Thanks

  2. #2

    Default

    Can you post some high quality pictures of the PCB and a schematic as well?

  3. #3
    Member
    Join Date
    Jan 2010
    Location
    Australia
    Posts
    96

    Default

    Quote Originally Posted by bpowell View Post
    Can you post some high quality pictures of the PCB and a schematic as well?
    Here is the board. Although I have used many of these boards in other installs with no issues over years. I don't have a schematic.
    Attached Images Attached Images

  4. #4
    Senior Member
    Join Date
    Jan 1970
    Location
    Perth, Western Australia
    Posts
    4,383

    Default

    Having to use the hard reset for loading software is usually related to your code - blocking commands in the previously loaded and running code in particular.

    The only other point I would make is that I would have a 100nF capacitor as close as possible to the PICAXE's power pins. Particularly when driving servos, which I suspect this board is for. However, if other copies of your board do not give trouble, then that is probably not the cause.

  5. #5
    Member
    Join Date
    Jan 2010
    Location
    Australia
    Posts
    96

    Default

    Thanks for the reply Pete.
    I did think that it might be code related. And this board is using and ERF module with two serial outputs. One real time data transmission and the other an ID byte. This is sent to a unit that reads out many different faults from other devices.
    And the board is also driving a H bridge circuit.

    The code is a bit rough. A bit shameful really

    The one odd thing I did to save on standby power with the ERF module and H bridge, was to power the ERF module and H bridge enable, through a high side NPN switch.

    I do give pause start up times for the ERF before data transmission etc.

    The whole thing works fine. But it is very possible that something in the code is causing problems.
    Last edited by matchbox; 12-01-2018 at 06:47.

  6. #6
    Senior Member
    Join Date
    Jan 1970
    Location
    NSW Australia
    Posts
    356

    Default

    Weird and erratic behaviour, I'd check the grounding. As Pete also suggested, good rail decoupling placed carefully near the PICaxe is a must.

    Just to clarify, you have been using the same design, the same program code and the same PCB in the past, with no changes and no issues? Is that correct? Is it running off the same test supply? Has anything (at all) changed recently?

    If you have a scope (microscope) I'd also suggest running over all of the PCB and pay particular attention to the SMD.
    Darb

  7. #7
    Member
    Join Date
    Jan 2010
    Location
    Australia
    Posts
    96

    Default

    That's correct. It has been working fine in the most part.

    I am not sure of the here after effect. But as I mentioned above, the RF module and H bridge driver turn on together, using the same NPN BJT, because I ran out of outputs to drive them individually. And the two together draw 48mA on standby.

    A possibility might be that the two turning on and off together could be forwarding a small spike up the output pin and in turn causing corruption in the picaxe output. It is only a SOT-23 with no biasing or current limiting and is high side switched. Maybe the little transistor is having a junction breaking down and feeding 5v into the output?

    I ordered a few P channel mosfets to replace this transistor and perhaps make the setup more rugged.

    Does the above theory sound logical?

  8. #8
    Technical Support
    Join Date
    Jan 1970
    Location
    UK
    Posts
    23,878

    Default

    Quote Originally Posted by matchbox View Post
    Does the above theory sound logical?
    Possibly. That you cannot download likely is that it is just waiting for something, not acknowledging the download request without a Hard Reset.

    The 'no outputs' situation could be a hardware latch-up or the code simply getting into a situation where there are no outputs and it is not moving on.

    Re-downloading the same code could put it into the same situation again or a hardware latch-up not being cleared.

    If an output program download works it may be that it was just the code jammed up going nowhere, rather than a hardware latch-up.

    I don't know if it would be the power switching transistor latching up an output or whether changing that would fix things. If a changes fixes things it might suggest that was the cause.

    It's almost impossible to say what's gone wrong when one can't see what's going on inside the 'black box'. It might be possible to alter the code so it indicates where it is, what it's doing, and what the outputs should be so you can get a better idea of what's going on when things stop working as expected.

  9. #9
    Senior Member
    Join Date
    Jan 1970
    Location
    NSW Australia
    Posts
    356

    Default

    Yeh matchbox, you really need to post your code and schematics for further help. As Hippy said, it's all a bit "black box" at the moment. Not sure why you don't have the schematics? Is it your design? At least post the code so others can see the structure. Everyone here is really helpful so the more information you give, the more chance you have of someone helping you resolve it. It's all speculation at the moment.

    I'm not convinced that changing what was a working hardware design is necessarily going to sort out the issue. Did ANYTHING change recently? Any (external) hardware changes? Any changes to the code?

    Here's what might seem like an obvious question, do you have another board (populated) with the same components AND loaded with the same code? If so, is it working?
    Darb

  10. #10
    Senior Member
    Join Date
    Jan 1970
    Location
    Perth, Western Australia
    Posts
    4,383

    Default

    Quote Originally Posted by matchbox View Post
    The one odd thing I did to save on standby power with the ERF module and H bridge, was to power the ERF module and H bridge enable, through a high side NPN switch.
    Are you sure that is correct? It is most unusual to use an NPN as a high-side switch. When using an NPN as a high-side switch, you will struggle to get the base voltage high enough to turn it on fully.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •