Everything seems to be working well, but if i set the FREQ to anything lower than 5 it just halts the computer and hitting RUN just single steps. This same behavior is seen when I use the pot with FREQ=0. FREQ values of 5-F work as expected.
Any advice?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The clock light behaves as you'd expect if you hit step to halt it. In other words it does not continue to flash.
I just noticed that every time it stops with the frequency set lower than five, all of the LED bits in A-Address, A-Data, and Write Data are stuck on. Vid attached using the "shortest loop" counter as an example.
U25 being bad might explain why the built in code at 10 doesn't run, too, yes?
I forgot that you were previously having a lot of unusual behavior due to some solder joint issues.
Can you single step through the built-in 10 "Euclid" code and verify that the program codes look the same as the listing shown in the Relay Trainer document. I suppose it is possible that somehow the U25 PIC micro-controller is somehow interpreting a HALT command when running at a <5 speed, which is why the "shortest loop" counter program stops, but then allows you to single step from there.
At this point I'm not sure if the U25 PIC IC/program is suspect or if there is still some issue with the PCB.
Last edit: Francis Bauer 2021-02-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, so I did a manual ASM to Machine code conversion and matched it to what's in memory address 10. Every line matches except for 1A which is 00.00.00.00 instead of C810FF00 (halt according to the docs).
I tried to manually enter C810FF00 into 1A and it won't take it. It will take 11111111, and it will take other codes, but if I try to put in HALT, it just reverts to 00.00.00.00
I then decided to try and put in the entire thing manually at position 20, converting the jump labels to their proper new addresses. The exact same thing happens, but this time with address 2A. Vid attached.
I then tried to enter C810FF00 into any address and I get the same behavior.
I cannot properly step through the program, either. The only time I seem to be able to step is with one-line programs that loop to themselves like the one-line counter. With the Euc program, it never gets past the first line. It deposits 90 into A, but then never goes any further.
This is a feature! (But definitely confusing). When a memory location contains HALT, the display shows only the low order byte, plus the low order bytes of successive words. HALT generally means that the address contains data instead of an instruction. This way you can watch more than one byte of data on the LED display.
The decimal points turn on when it is doing this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ive done some more testing. Any program more than one line fails. Looking at the instruction sequence from here it seems to be because both'wra' and 'wrb' are set after the first line is executed. To prove this, I wrote a simple 6-line program where bb is 00:
This should end up with the contents of 00 being 5, but it never makes it past the first line.
After the first line is executed, both 'wra' and 'wrb' are set. Since 48 is 01001000, only 'wrb' should be set, assuming I understand the architecture of the system correctly. This is true whether I run or step. Vid attached to show this in action.
This behavior is the same when running the Euc program since the first line of that has an opcode starting with 48.
So now the question is, why is this happening and how do I fix it?
I think the root cause of the above behavior is that the program counter is going to zero. Based on the previous commnt about the halt statement and reading somewhere that memory is filled with halts as a default, coupled with the fact that all the PC LEDs are off when it stops, that would make sense to me. Looking at the LEDs certainly seems to indicate a PC of 00 and the data at 00 looking like 00FFFF01 (01 because it incremented once)
Last edit: Gary Donahue 2021-02-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well I think I fried my PIC(s) because I connected the serial cable to the wrong headers and before I realized it the cable got hot and now the relay trainer appears to be dead.
How can I go about ordering replacement PICs?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Everything seems to be working well, but if i set the FREQ to anything lower than 5 it just halts the computer and hitting RUN just single steps. This same behavior is seen when I use the pot with FREQ=0. FREQ values of 5-F work as expected.
Any advice?
I'm assuming that the clock LED also doesn't show a continuous clock cycling with settings below 5.
This sounds like a problem with the U25 PIC micro-controller's program itself, since it is what generates the clock for the Relay portion of the unit.
Other than getting and programming a new PIC micro-controller I don't know what else you could try... :-(
The clock light behaves as you'd expect if you hit step to halt it. In other words it does not continue to flash.
I just noticed that every time it stops with the frequency set lower than five, all of the LED bits in A-Address, A-Data, and Write Data are stuck on. Vid attached using the "shortest loop" counter as an example.
U25 being bad might explain why the built in code at 10 doesn't run, too, yes?
Last edit: Gary Donahue 2021-02-05
I forgot that you were previously having a lot of unusual behavior due to some solder joint issues.
Can you single step through the built-in 10 "Euclid" code and verify that the program codes look the same as the listing shown in the Relay Trainer document. I suppose it is possible that somehow the U25 PIC micro-controller is somehow interpreting a HALT command when running at a <5 speed, which is why the "shortest loop" counter program stops, but then allows you to single step from there.
At this point I'm not sure if the U25 PIC IC/program is suspect or if there is still some issue with the PCB.
Last edit: Francis Bauer 2021-02-05
OK, so I did a manual ASM to Machine code conversion and matched it to what's in memory address 10. Every line matches except for 1A which is 00.00.00.00 instead of C810FF00 (halt according to the docs).
I tried to manually enter C810FF00 into 1A and it won't take it. It will take 11111111, and it will take other codes, but if I try to put in HALT, it just reverts to 00.00.00.00
I then decided to try and put in the entire thing manually at position 20, converting the jump labels to their proper new addresses. The exact same thing happens, but this time with address 2A. Vid attached.
I then tried to enter C810FF00 into any address and I get the same behavior.
I cannot properly step through the program, either. The only time I seem to be able to step is with one-line programs that loop to themselves like the one-line counter. With the Euc program, it never gets past the first line. It deposits 90 into A, but then never goes any further.
Last edit: Gary Donahue 2021-02-05
This is a feature! (But definitely confusing). When a memory location contains HALT, the display shows only the low order byte, plus the low order bytes of successive words. HALT generally means that the address contains data instead of an instruction. This way you can watch more than one byte of data on the LED display.
The decimal points turn on when it is doing this.
Thanks! That makes sense.
Now to figure out why the programs won't run.
Ive done some more testing. Any program more than one line fails. Looking at the instruction sequence from here it seems to be because both'wra' and 'wrb' are set after the first line is executed. To prove this, I wrote a simple 6-line program where bb is 00:
This should end up with the contents of 00 being 5, but it never makes it past the first line.
After the first line is executed, both 'wra' and 'wrb' are set. Since 48 is 01001000, only 'wrb' should be set, assuming I understand the architecture of the system correctly. This is true whether I run or step. Vid attached to show this in action.
This behavior is the same when running the Euc program since the first line of that has an opcode starting with 48.
So now the question is, why is this happening and how do I fix it?
I think the root cause of the above behavior is that the program counter is going to zero. Based on the previous commnt about the halt statement and reading somewhere that memory is filled with halts as a default, coupled with the fact that all the PC LEDs are off when it stops, that would make sense to me. Looking at the LEDs certainly seems to indicate a PC of 00 and the data at 00 looking like 00FFFF01 (01 because it incremented once)
Last edit: Gary Donahue 2021-02-07
Well I think I fried my PIC(s) because I connected the serial cable to the wrong headers and before I realized it the cable got hot and now the relay trainer appears to be dead.
How can I go about ordering replacement PICs?
Been there done that too :-(
After frying my PIC I put an empty plug onto the PIC programming header to keep me from destroying another one.
Joe was kind enough to send me a replacement, hopefully he will see these messages and respond.
Joe hooked me up as well. Thanks!