Alternate Piicaxe Programming Circuit

CDRIVE

Senior Member
My current Picaxe project involves replacing an unlabeled 12F series SMD chip with a 08M2(SMD) chip. The 12F uC is located on an electronic bike horn with 5 selectable tones that are selected by pressing the ToneSelSw shown in the attachment. As you can see, this switch is utilizing the SerIn (programming) pin for the 08M2. Since I don't want to do a lot of exactoknife surgery on this board I need to employ the alternate programming circuit shown.

Personally, I don't see why my alternate programmer design shouldn't work but I thought I'd post this before testing this approach.

Thanks,
Chris
 

Attachments

BeanieBots

Moderator
Personally, I don't see how it CAN work.
Perhaps you could explain your reasoning behind the alternative design.
 

hippy

Technical Support
Staff member
The 10K pull-up will cause the PICAXE to continually think there's a download being initiated so will never begin to run your program until you push the button. However, if you are okay with pushing the button to make the program start whenever you turn the horn power on it could work.

I haven't analysed your actual download buffering circuit.
 

CDRIVE

Senior Member
Personally, I don't see how it CAN work.
Perhaps you could explain your reasoning behind the alternative design.
I provided a simplified schematic of the Bike Horn circuit. I would think that my "reasoning" would be self explanatory.
The PICAXE will never boot into your program if the SerIn pin is pulled high at boot up.
As Hippy quotes below this is not an issue. The existing ToneSel switch will be used to initiate the existing program upon boot up. Subsequently the ToneSel switch will be used to branch the program to the selected tone. There's another (logic low) switch (not shown) connected to physical pin3. This switch is the Horn switch.

The 10K pull-up will cause the PICAXE to continually think there's a download being initiated so will never begin to run your program until you push the button. However, if you are okay with pushing the button to make the program start whenever you turn the horn power on it could work.

I haven't analysed your actual download buffering circuit.
Thank you Hippy. No, there's no issue with closing the ToneSel switch to initiate the existing program upon boot up.

If you or others are interested I will post the complete (reverse engineered) schematic of the Bike Horn and photos too.

Thanks again,
Chris
 

CDRIVE

Senior Member
Hmm. There seems to be some sort of disconnect here. Let us know when you get it working.
"Disconnect" is the operative term here, as my program will include this command. This should prevent the Picaxe from scanning for a new program except at boot up. Boot up only happens with cell replacement as power to the OEM horn board is always on when two AAA cells are installed.

Chris
 

hippy

Technical Support
Staff member
It might be worth modelling the new horn and download circuit using a DIL version of the 08M2 to get everything working first, before making mods to the horn and then finding you need to rework that again.

With the existing chip removed it might be easier to cut and reroute components or tracks. You can leave some chip legs stuck up and connect flying wires to those to save on some cutting or to make things easier.
 

CDRIVE

Senior Member
It might be worth modelling the new horn and download circuit using a DIL version of the 08M2 to get everything working first, before making mods to the horn and then finding you need to rework that again.

With the existing chip removed it might be easier to cut and reroute components or tracks. You can leave some chip legs stuck up and connect flying wires to those to save on some cutting or to make things easier.
Yes, that's exactly what I had planned to do. I'm a retired EET and am not senile enough (yet) to not breadboard first. :p I have lots of DIL 08M2's.

As for chopping and hacking... When I pull the OEM chip I'll make my assessment but I have to keep in mind that I have 4 horns to modify. The less chop & hack the better.
Thanks,
Chris
 

CDRIVE

Senior Member
Well, as it turned out I didn't have any (DIL) 08M2 parts, just a lot of 08M's. After waiting to receive some M2's I breadboarded the circuit and I'm happy to say it worked as expected and exactly as Hippy described it would. The only problem I encountered, which had me pulling hair, was that the "Disconnect" command seemed to brick the chip! After repeated failed attempts at executing a Hard Reset I gave up doing this with V6.0.8.0 and tried it using my old V5.5.0.5. Viola! It cleared the program.

I probably will be starting another topic regarding the "Disconnect" & "Reconnect" commands because I think the PDF descriptions are a bit ambiguous or possibly a bit confusing. This was my basic test code which I'm beginning to believe should have the Reconnect & Disconnect commands swapped as depicted in the PDF code examples. If so then I'm not fully understanding these two commands.

Code:
Reconnect
Main:
    If pin5=0 then
        High 2
    Else Low 2
    End If
Disconnect
GoTo Main
Thanks,
Chris
 

CDRIVE

Senior Member
For those interested in the alternate programming test circuit using the code in my last post, I've attached a schematic.

Chris

Axe090PgmngCir2.JPG
 

hippy

Technical Support
Staff member
DISCONNECT stops a high on Download Serial In from initiating a download, RECONNECT allows that.

So, if you want to test the signal on PinC.5 you need a DISCONNECT.

Your code probably appears to work but that will be the PICAXE resetting and initiating download which is probably causing output 2 to appear low, not the PICAXE program.

A better test would be -

Code:
Disconnect
Do
  If pinC.5 = 0 Then
    High C.2 : Pause 500 : Low C.2 : Pause 500
  Else
    High C.2 : Pause 100 : Low C.2 : Pause 400
  End If
Loop
In this case you will get a toggle or a pulsed output.

Take the DISCONNECT out, or add a RECONNECT after DISCONNECT, and you will get static on ( or off ), or a toggle.
 

CDRIVE

Senior Member
Hippy, thanks for the code and explanation. I will give it a go. In the interim please explain the following code from the Basic Commands PDF. I don't understand how the chip sees the SerRxd code when the Disconnect command preceded it. It seems counter intuitive. I thought that once Disconnect is loaded into the chip's program memory it would not download any subsequent code. I hope I'm explaining myself correctly.

Code:
disconnect
serrxd [1000, timeout],@ptrinc,@ptrinc,@ptr
reconnect
Thanks,
Chris
 

rossko57

Senior Member
I thought that once Disconnect is loaded into the chip's program memory it would not download any subsequent code.
That's correct ; once Disconnect is executed, serial data arriving is not treated as program code and not used to reprogram the chip.

But that does not stop your pre-loaded program treating it as plain old data, like any other serial pin, and doing whatever else you want with it.
 

hippy

Technical Support
Staff member
Think of it as 'disconnect the internal download detector'; it allows the pin to be used without signals on the pin triggering the download detector.

SERRXD can only read serial from the PC (or elsewhere) once the DISCONNECT has been issued, otherwise anything sent would trigger the download detector rather than be read by the program. In fact it's impossible to use SERRXD without a DISCONNECT first so SERRXD includes an implicit DISCONNECT.
 

CDRIVE

Senior Member
Think of it as 'disconnect the internal download detector'; it allows the pin to be used without signals on the pin triggering the download detector.

<snip>
Thanks Hippy, I think that explanation cleared things up but just to be certain here's a simple True or False question. If there is no "Reconnect" command included are the 'results' of these two lines of code any different?

Code:
disconnect
serrxd [1000, timeout],@ptrinc,@ptrinc,@ptr
Code:
serrxd [1000, timeout],@ptrinc,@ptrinc,@ptr
disconnect
Thank you,
Chris
 

AllyCat

Senior Member
Hi Chris,

No, there should be no difference because in both cases the SERRXD generates a disconnect and the actual DISCONNECT command is unnecessary.

Personally, I always try to include a RECONNECT command in my code, typically after the timeout label. Then I don't (usually) have to bother with hard resets (which don't seem as easy or reliable on PE6, compared with PE5).

Cheers, Alan.
 

CDRIVE

Senior Member
Hi Chris,

No, there should be no difference because in both cases the SERRXD generates a disconnect and the actual DISCONNECT command is unnecessary.

Personally, I always try to include a RECONNECT command in my code, typically after the timeout label. Then I don't (usually) have to bother with hard resets (which don't seem as easy or reliable on PE6, compared with PE5).

Cheers, Alan.
Thanks for the info Alan. I thought I was doing something wrong but like you I had to revert to V5 to do a hard reset. I just couldn't get V6 to do it.

Chris
 

Technical

Technical Support
Staff member
In PE6 flick across to the compiler tab on the workspace explorer. It then explicitly tells you when to connect the power for a hard reset.

CaptureHardReset.PNG
 

hippy

Technical Support
Staff member
I have not had any problems with Hard Reset using PE6, not found it any less reliable than PE5.

Power off, initiate download, wait for the "Searching for hardware..." message at the bottom right of the status panel, power on, works reliably for me.
 

CDRIVE

Senior Member
Ha, I guess I should spend more time familiarizing myself with the PE7 IDE.

On another note many times answered questions begets more more questions that diverge from the topic title. The existence of the compiler window has triggered my appetite for my next project. That would be to totally automate the Hard Reset procedure by hooking into the compiler via VB6 API and hardware (power ON) interface circuit. Though I have a suspicion that my next question will steer me in a different direction....

Would you please tell me if when the compiler displays "Connect Power Now!" there is a corresponding signal present on the PC's serial port TXD line? If so, what is the data being transmitted from PE6 to the SerRxd pin of the Picaxe? If it can be read by another 08M2 via SerIn function I can tap into PC's TXD line, decode the data and automate a Power On circuit. It would be a fun project as well as being useful.

Thanks,
Chris
 

hippy

Technical Support
Staff member
It is possible. When the "Connect power / Searching for hardware" message appears a break signal will be generated; the Download Serial In pin will be taken high, and stay high until the PICAXE has responded, or the PC gives up on the download with "Hardware not found". Just look for the signal going high, or goes high for long enough to confirm a break is being generated.
 

CDRIVE

Senior Member
Oh, that's sweet! This is going to be simpler that I thought but as usual prompts another question. ..

When the Picaxe recognizes the Break signal what does it send back to the PC? Does it just echo the Break signal or is it a data packet?

Thanks Hippy!
 

hippy

Technical Support
Staff member
What happens after the PICAXE sees the break is proprietary and not published information.
 

CDRIVE

Senior Member
Well, I guess I'm going to be sleuthing with a scope or use software such as PortMon. On the other hand if the Picaxe simply doesn't respond before the PC timeout that may be sufficient to include a Reset To Power Off circuit.

Thanks,
Chris
 

hippy

Technical Support
Staff member
You do not have to do anything but spot the prolonged high break for an 'auto-power it on at download' controller, and likewise detect a prolonged low / idle signal to turn power off after programming.
 

CDRIVE

Senior Member
Roger that Hippy. It will be my next project. For now I have to get back to the topic of this thread and try the code you gave me to test. I've been sidetracked by many things but I should be posting the results soon.

Thanks again,
Chris
 

CDRIVE

Senior Member
Hippy, I ran your code sample with a slight mod as shown and it's running fine with the SerIn (C.5) held high through the 10K pull-up as shown on my two schematics.
The chip also reacts as you predicted it would when powering up. Pushing the Tone button to kick start the program is not a problem though. .. Thanks!
Code:
Disconnect
Do
  If pinC.5 = 0 Then
    High C.2 : Pause 500 : Low C.2 : Pause 500
  Else
    High C.2 : Pause 400 : Low C.2 : Pause 100
  End If
   If PinC.1 = 1 Then
        GoTo RST
    EndIf    
Loop

RST:
High C.4: Wait 3: Reconnect
For those that posted their doubts about this working I must say that I can see why. The Getting Started PDF makes repeated warnings about not letting the SerIn pin float or be held high. Fortunately I'm happy to report that the Disconnect command does seem to negate this issue.

Thanks to all,
Chris
 

CDRIVE

Senior Member
Hi Chris,

No, there should be no difference because in both cases the SERRXD generates a disconnect and the actual DISCONNECT command is unnecessary.

Personally, I always try to include a RECONNECT command in my code, typically after the timeout label. Then I don't (usually) have to bother with hard resets (which don't seem as easy or reliable on PE6, compared with PE5).

Cheers, Alan.
Hi Alan, Since I'm not using the programming input pin for serial com the TimeOut qualifier used with SerRxd is not applicable in my application, or is it? Perhaps if I code the pin to look for a logic low > 4 seconds and branch to SerRXd I can then use TimeOut?

Obviously it seems I'm in need of a bit more help with the Reconnect command. Because this project involves modification of an existing product I have very limited space to add any hardware, other than a stereo programming jack. There is no Power switch on the bike horn so performing a Hard Reset would involve inserting batteries at the exact moment. This would be a royal PETA.

I understand that the Reconnect command will tell the chip to resume 'periodically' checking for a Break signal on the programming input pin ("Quote:Hippy") but I'm not quite sure when this occurs.

(1) Does the chip do this check anywhere within the program or wait till the program cycles back to the first line of code?
(2) Does Wait or Pause within a program effect execution of Reconnect?
(3) If C.5 is held low > 4 Sec will branching my program to an endless loop containing nothing but "Reconnect" solve my problem?
(4) Will Wait or Pause aid or inhibit execution of Reconnect within this loop?


Than you,
Chris
 

AllyCat

Senior Member
Hi Chris,

AFAIK, the Programming pin is tested after EVERY instruction (and maybe also during a PAUSE). So if you insist on pulling the SerIn pin high during "normal" operation then you can't use a RECONNECT, because the PICaxe will just keep waiting for a new download (and start running from the start when/if Serin goes low).

However, if you want to use a "long" push of the button to re-enter programming mode, then you could simply issue a RECONNECT command after the appropriate delay and then ensure that the program does NOT issue another DISCONNECT.

I'm surprised that you have space for the Programming socket, but as you do, note that it has two internal switches. One switch is connected to earth and becomes open-circuit when the plug is inserted. I don't know of all your constraints, but the solution I would use is to connect that switch to a spare PICaxe pin (which could even be the Serial-Out pin if really necessary). The pin would be pulled low when the Programming plug is disconnected, so the program can enable the internal weak pullup resistor for that pin and periodically test it to see when the programming plug is re-connected (i.e. pin high). Then it can issue a RECONNECT, after a suitable time delay if necessary.

Cherrs, Alan.
 

CDRIVE

Senior Member
Hi Chris,

AFAIK, the Programming pin is tested after EVERY instruction (and maybe also during a PAUSE). So if you insist on pulling the SerIn pin high during "normal" operation then you can't use a RECONNECT, because the PICaxe will just keep waiting for a new download (and start running from the start when/if Serin goes low).

However, if you want to use a "long" push of the button to re-enter programming mode, then you could simply issue a RECONNECT command after the appropriate delay and then ensure that the program does NOT issue another DISCONNECT.

I'm surprised that you have space for the Programming socket, but as you do, note that it has two internal switches. One switch is connected to earth and becomes open-circuit when the plug is inserted. I don't know of all your constraints, but the solution I would use is to connect that switch to a spare PICaxe pin (which could even be the Serial-Out pin if really necessary). The pin would be pulled low when the Programming plug is disconnected, so the program can enable the internal weak pullup resistor for that pin and periodically test it to see when the programming plug is re-connected (i.e. pin high). Then it can issue a RECONNECT, after a suitable time delay if necessary.

Cherrs, Alan.
Hi Alan,
I was anxious to give you an immediate reply but I wanted to get all my ducks in a row first.

I really do like your idea of using the programming jack's switch contact, though I wouldn't use it as you described. After multiple failed attempts at structuring a bomb proof Reconnect procedure, which always culminated in requiring a Hard Reset procedure, I stumbled upon a statement found in one of the PDF help files that triggered a "Eureka!" moment for me. Unfortunately I don't remember which manual or page number. Anyway, this brief blurb stated that when a Reconnect command is executed it automatically issues a chip Reset! This explains why absolutely all my test code failed to Reconnect. It didn't matter if I placed Reconnect in an endless loop with no exit procedure. As soon as Reconnect was executed my chip would exit the loop and branch to the start of the program that contains the Disconnect command. The chip would then fall back into my main program loop and NOT look for the Break signal on the programming pin!

Solution: After realizing the Reset issue involved with the Reconnect command it became obvious that the logic of my code needed to be reversed. Instead of issuing a Reconnect and hoping the chip will catch a Break signal from PE6 I changed my code to look for the Break signal and have the Break signal trigger Reconnect. So far, I've tested it 10 times and it's working flawlessly. I can't express enough how pleasing it is to NOT see a PE6 error message of "Download Failed! MCU or ComPort not found"!

The Reconnect code below is a secondary loop outside of my main program. The main program branches to this loop when the Axe027 mini plug opens the GND contact on the programming jack.

Code:
Do 
    'Reconnect  'DON'T DO THIS!!!
    High C.4
    Pause 100
    Low C.4
    Pause 100
        If PinC.5 = 1 Then    'Break Signal Detected
            Reconnect  'Eureka! This Works!
        End If
Loop
I think it's worth noting that the PE5 & PE6 simulators do not simulate Reconnect properly. While Reconnect also issues a Reset on the chip it's not executed in the simulator! Can it be I'm the first to have discovered this?

When a Reset is explicitly used PE6 will place a separator line directly below it. This lets the developer know that nothing below that line will be executed. I think Reconnect should be handled and displayed the same way.

BTW, I'm not sure I have the real estate to use the typical Picaxe (Con039) programming jack on my bike horn. There's no room to put it on the PCB and I was planning to use a small stereo panel mount connector by drilling a hole in the case. If I can fit it I did find panel mount versions of the Axe Con039 (with switch contacts) on Ebay.

Cheers,
Chris
 

AllyCat

Senior Member
Hi Chris,

when a Reconnect command is executed it automatically issues a chip Reset!

I think it's worth noting that the PE5 & PE6 simulators do not simulate Reconnect properly.
AFAIK that is not correct. The RECONNECT will ONLY cause a reset if the SerIn pin is (still) held high (which is the actual cause of the reset).

Also, I believe there was a thread a few week ago where somebody was complaining that pinc.5 on an 08M2 does not simulate correctly in PE6. Hippy's response was that it was simulating correctly (not toggling the pin) because a high on the pin (without a DISCONNECT issued) was causing an immediate reset. However, it does seem that PE5 does not simulate a reset correctly.

Cheers, Alan.
 

hippy

Technical Support
Staff member
^ What AllyCat says.

The RECONNECT does not cause a reset, but a high on the Download Serial In at the time RECONNECT is issued or thereafter will cause the PICAXE to enter download mode which will lead to a reset later.

I cannot tell if your RECONNECT code is robust without seeing the rest of the code and having a full explanation of the reprogramming sequence you are using, but if it works and you are happy with it, then that would be what matters most.

The earlier simulation issue was related to behaviour with DISCONNECT, not behaviour with RECONNECT. What you have is an edge-case which would not be recommended, 'fudging a non-standard configuration to make it work', so it is not a case which would normally be simulated. There may be issues with simulating RECONNECT and interacting with the Serial Download Pin state which would need investigating.
 

CDRIVE

Senior Member
Thanks for the replies Mates.

I will post my cleaned up code after I do more testing between real world PE6 download and the PE6 simulator. At this point all my real world tests conflict with what the simulator does. I find this odd because the PE simulators have always been been a reliable representation of real world operation. Real world tests are working flawlessly for both running the existing test program as well as accepting a new download.

Thanks,
Chris
 

hippy

Technical Support
Staff member
At this point all my real world tests conflict with what the simulator does. I find this odd because the PE simulators have always been been a reliable representation of real world operation.
You are using an active low button on Download Serial In with a pull-up which is the opposite of what would normally be used with a PICAXE and there is a fair likelihood that what you are presenting to the simulator does not reflect what the physical hardware is doing.

It would be necessary to know what your program and circuit is and the full and exact procedures you are using to initiate a subsequent download to really analyse further as that will affect the hardware state.
 

CDRIVE

Senior Member
You are using an active low button on Download Serial In with a pull-up which is the opposite of what would normally be used with a PICAXE and there is a fair likelihood that what you are presenting to the simulator does not reflect what the physical hardware is doing.

It would be necessary to know what your program and circuit is and the full and exact procedures you are using to initiate a subsequent download to really analyse further as that will affect the hardware state.
Hippy, I've attached my cleaned up and sped up code including my most current test circuit built on an Axe090 experimenter board. Note that PinC.5 is held low when S1 is (closed) in Programming Mode. It stays low until Break is received.

Note that when you simulate it you will see (what appears to be) odd behavior. If you exit the first loop (click PinC.1 High) by first making C.5 high (simulate Break sig) the simulator should first exit the program test loop, branch to the RePgm loop, see PinC.5 high and trigger a simulated Reset when Reconnect is executed.

Hi Chris,



AFAIK that is not correct. The RECONNECT will ONLY cause a reset if the SerIn pin is (still) held high (which is the actual cause of the reset).

Also, I believe there was a thread a few week ago where somebody was complaining that pinc.5 on an 08M2 does not simulate correctly in PE6. Hippy's response was that it was simulating correctly (not toggling the pin) because a high on the pin (without a DISCONNECT issued) was causing an immediate reset. However, it does seem that PE5 does not simulate a reset correctly.

Cheers, Alan.
Hi Alan,

I've been a stubborn cuss all my life and now pushing 70 hasn't changed that. In fact I think I'm more stubborn now! So after reading your reply I spent over 2 hours searching (stubbornly) through all the PDF's, desperately hoping to find, what I thought would be evidence, bolstering my Reconnect statements. I found NADA!
What I did find only confirms your "AFAIK". What I thought I read doesn't seem to exist! Maybe senility is creeping in?

Failing dismally to provide evidence in the PDF's I moved on to my test circuit to further analyze what the chip is doing. The only thing I was able to affirm is the following... If the developer wants to insure anything that resembles "reliable" and "consistent" Reconnect (to facilitate a new download), use the PE's download (Break Signal) to initiate the Reconnect as I did. I tried all sorts of code structures but even with the Serial In pin held low and a Disconnect executed new Downloads would consistently fail. Using a new download's (Break signal) to trigger the Reconnect hasn't failed after at least 20 times by now.

Code:
 ;http://www.picaxeforum.co.uk/showthread.php?27906-Alternate-Piicaxe-Programming-Circuit&p=289092&viewfull=1#post289092
 'Note1: This code works flawlessly in the chip. Do not modify!
 
 'Axe090 (Bike Horn Test Circuit)Reprogramming procedure: 
 '(1)Switch Run/Programming switch to Program. 
 '(2)Press SW2 to exit main program and look for new program (Break sig)download
 ' within the RePgm loop. The PE6 Break =~6sec when no response is received from
 ' the chip.
 
 'Simulator Notes: The simulator does not seem to fire a Reset when PinC.5 is 
 'clicked high as it does in the real world.
 
Disconnect
'Provide indication that chip has Disconnected
For B0=1 to 100
    High C.2
    Pause 5
    Low C.2
    Pause 40
Next 
    
'Provide indication that PinC.5 is responding to logic input.    
Do
  If pinC.5 = 0 Then
    Low C.2 : Pause 100 : High C.2 : Pause 100 '500: 500
  Else
    Low C.2 : Pause 500 : High C.2 : Pause 500  '400:100
  End If
   If PinC.1 = 1 Then
        'Wait 1
        GoTo RePgm   '(A) will be replaced with Exit
    EndIf    
Loop

RePgm:             ' remove if (A) is true

Do 
    If PinC.5 = 1 Then
        Reconnect 
    End If
        High C.4  'provide indication that chip has Reconnected & is waiting for- 
        Pause 5   'a new download.
        Low C.4
        Pause 40
Loop
Thanks,
ChrisAxePgmngCir2.JPG
 

CDRIVE

Senior Member
You are using an active low button on Download Serial In with a pull-up which is the opposite of what would normally be used with a PICAXE and there is a fair likelihood that what you are presenting to the simulator does not reflect what the physical hardware is doing.

It would be necessary to know what your program and circuit is and the full and exact procedures you are using to initiate a subsequent download to really analyse further as that will affect the hardware state.
Hippy, I've attached my cleaned up and sped up code including my most current test circuit built on an Axe090 experimenter board. Note that PinC.5 is held low when S1 is (closed) in Programming Mode. It stays low until Break is received.

Note that when you simulate it you will see (what appears to be) odd behavior. If you exit the first loop (click PinC.1 High) by first making C.5 high (simulate Break sig) the simulator should first exit the program test loop, branch to the RePgm loop, see PinC.5 high and trigger a simulated Reset when Reconnect is executed.

Hi Chris,



AFAIK that is not correct. The RECONNECT will ONLY cause a reset if the SerIn pin is (still) held high (which is the actual cause of the reset).

Also, I believe there was a thread a few week ago where somebody was complaining that pinc.5 on an 08M2 does not simulate correctly in PE6. Hippy's response was that it was simulating correctly (not toggling the pin) because a high on the pin (without a DISCONNECT issued) was causing an immediate reset. However, it does seem that PE5 does not simulate a reset correctly.

Cheers, Alan.
Hi Alan,

I've been a stubborn cuss all my life and now pushing 70 hasn't changed that. In fact I think I'm more stubborn now! So after reading your reply I spent over 2 hours searching (stubbornly) through all the PDF's, desperately hoping to find, what I thought would be evidence, bolstering my Reconnect statements. I found NADA!
What I did find only confirms your "AFAIK". What I thought I read doesn't seem to exist! Maybe senility is creeping in?

Failing dismally to provide evidence in the PDF's I moved on to my test circuit to further analyze what the chip is doing. The only thing I was able to affirm is the following... If the developer wants to insure anything that resembles "reliable" and "consistent" Reconnect (to facilitate a new download), use the PE's download (Break Signal) to initiate the Reconnect as I did. I tried all sorts of code structures but even with the Serial In pin held low and a Disconnect executed new Downloads would consistently fail. Using a new download's (Break signal) to trigger the Reconnect hasn't failed after at least 20 times by now.

Code:
 ;http://www.picaxeforum.co.uk/showthread.php?27906-Alternate-Piicaxe-Programming-Circuit&p=289092&viewfull=1#post289092
 'Note1: This code works flawlessly in the chip. Do not modify!
 
 'Axe090 (Bike Horn Test Circuit)Reprogramming procedure: 
 '(1)Switch Run/Programming switch to Program. 
 '(2)Press SW2 to exit main program and look for new program (Break sig)download
 ' within the RePgm loop. The PE6 Break =~6sec when no response is received from
 ' the chip.
 
 'Simulator Notes: The simulator does not seem to fire a Reset when PinC.5 is 
 'clicked high as it does in the real world.
 
Disconnect
'Provide indication that chip has Disconnected
For B0=1 to 100
    High C.2
    Pause 5
    Low C.2
    Pause 40
Next 
    
'Provide indication that PinC.5 is responding to logic input.    
Do
  If pinC.5 = 0 Then
    Low C.2 : Pause 100 : High C.2 : Pause 100 '500: 500
  Else
    Low C.2 : Pause 500 : High C.2 : Pause 500  '400:100
  End If
   If PinC.1 = 1 Then
        'Wait 1
        GoTo RePgm   '(A) will be replaced with Exit
    EndIf    
Loop

RePgm:             ' remove if (A) is true

Do 
    If PinC.5 = 1 Then
        Reconnect 
    End If
        High C.4  'provide indication that chip has Reconnected & is waiting for- 
        Pause 5   'a new download.
        Low C.4
        Pause 40
Loop
Thanks,
ChrisView attachment 18703
 

Attachments

hippy

Technical Support
Staff member
Note that PinC.5 is held low when S1 is (closed) in Programming Mode. It stays low until Break is received.
The break signal won't be seen by the PICAXE if S1 is closed.

Note that when you simulate it you will see (what appears to be) odd behavior. If you exit the first loop (click PinC.1 High) by first making C.5 high (simulate Break sig) the simulator should first exit the program test loop, branch to the RePgm loop, see PinC.5 high and trigger a simulated Reset when Reconnect is executed.
It should and it is an issue which has been logged. This is the edge case which had not been expected, that Download Serial In would be high when a RECONNECT was issued.

Because you know the Download Serial In is high when RECONNECT is executed, as a workround you can RESET after the RECONNECT to match the behaviour of the physical hardware.
 

CDRIVE

Senior Member
The break signal won't be seen by the PICAXE if S1 is closed.
Why do you think that? If there's no Break signal Q1's base is low making Q1 collector high, which makes Q2's base high and thus its collector (PinC.5) low. When Break is received the inverse is true. PinC.5 will be high.

Also, please note that (in the simulator) if PinC.5 is low when entering the RePgm loop it still won't reset when clicked high

Chris
 

hippy

Technical Support
Staff member
Why do you think that? If there's no Break signal Q1's base is low making Q1 collector high, which makes Q2's base high and thus its collector (PinC.5) low. When Break is received the inverse is true. PinC.5 will be high.
If S1 is closed it will be shorting Download Serial In (C.5) to 0V so it won't see a break signal. I suspect that I am reading your earlier comment differently to how you actually mean - "Note that PinC.5 is held low when S1 is (closed) in Programming Mode. It stays low until Break is received".

Also, please note that (in the simulator) if PinC.5 is low when entering the RePgm loop it still won't reset when clicked high
No, because at that point you won't have issued a RECONNECT. As soon as C.5 is detected as high, the RECONNECT is executed but there is no reset because it is that edge case bug noted earlier. Put a RESET after RECONNECT and it will behave as expected as described earlier.
 
Top