Home Automation Domotica Forum Europe, Bwired Forum

I have build the OTG from a PCB and a programmed PIC. It worked OK after I made the suggested omitting of the RS232 chip IC2.
My problems began when I attempted to program the diagnose.hex on the Chip using the otmonitor software on the RaspberryPi.
The programming went well I thought but when clicking the Diagnose link it produced a series of dots:
................................. slowly increasing in numbers.
So I went back to programming the gateway.hex again. This time on a Win7 system. That went well also, until I thought let me program diagnose.hex again to see if all is well with the communication between my Honeywell Basic Stat Modulation Thermostat. That thermostat does not seem to work with the gateway

Now it went wrong. I clicked on the program button. The software did ask me to manually reset the gateway, but this did not work anymore like before.
No matter how often I clicked on program, It did not want to program the PIC anymore. So I had to remove the soldered PIC from the PCB and get another one

I bought a clean PIC 16F88 but now I need to use a PIC programmer to get gateway.hex on it or do I ?? As far as I can understand Schelte's site (http://otgw.tclcode.com)
It self-programming only works with a PIC that has been programmed with a working gateway patch I understand.
Has anyone on this forum experienced the same puzzling output from the diagnose command (......................?)

Please be precise when reporting what you did. Otherwise your audience has to guess, which doesn't help with the problem resolution. What is the "Diagnose link"? Do you mean the "Diagnostics" entry in the File menu? The diagnostics window should actually automatically appear when you have loaded the diagnostic firmware.

I've heard before of people seeing semicolons with the diagnostic firmware, but not dots. See for example:
https://www.domoticaforum.eu/viewtopic.php?f=75&t=10267
https://www.domoticaforum.eu/viewtopic.php?f=75&t=10750
https://www.domoticaforum.eu/viewtopic. ... 315#p77606

How did you manually reset the gateway? What do you mean by "this did not work anymore like before"? If resetting the gateway does not work, you're doing it wrong. In the worst case, pull the plug of the gateway, wait a few seconds and then plug it in again.

Or do you mean that programming the PIC still didn't work if you manually reset the gateway when prompted? Did you reset the gateway in time? You have 60 seconds to do that. Please also indicate what otmonitor reports. I put those messages in there for a reason. For example, "Firmware update failed - 397 errors" will point in a different direction than "Could not switch gateway to self-programming mode".

I took great care to make the bootloader as robust as possible. It should be almost impossible to end up in a situation where the PIC cannot be reflashed, unless the PIC is broken. Which is why I always recommend to put the PIC in a socket. In the exceptional case that a good PIC loses its self-programming ability, a small PCB modification could actually allow you to reflash it in-circuit. For more information see: https://www.domoticaforum.eu/viewtopic. ... 934#p61940

hvxl wrote:...Please be precise when reporting what you did. Otherwise your audience has to guess, which doesn't help with the problem resolution. What is the "Diagnose link"? Do you mean the "Diagnostics" entry in the File menu? The diagnostics window should actually automatically appear when you have loaded the diagnostic firmware....

Yes 'Diagnostics' is what i meant. But after programming the PIC I had to manually click The file menu -> diagnostics to open the Diagnostics window. Then it produced the line of dots.
I am suspecting the USB to Serial cable now, although it worked well until this occurred.

hvxl wrote:...did you mean that programming the PIC still didn't work if you manually reset the gateway when prompted? Did you reset the gateway in time? You have 60 seconds to do that. Please also indicate what otmonitor reports. I put those messages in there for a reason. For example, "Firmware update failed - 397 errors" will point in a different direction than "Could not switch gateway to self-programming mode"....

I did reset the Gateway manually in time. The otmonitor prompted with something like: ' could not open self-programming mode'

hvxl wrote:...I took great care to make the bootloader as robust as possible. It should be almost impossible to end up in a situation where the PIC cannot be reflashed, unless the PIC is broken...

You did a very good job with this project and I am not blaming anyone for my own faults (if any)
The PIC is probably broken. but thank you very much Schelte for the useful tips in your reply.
I ordered a PIC Programmer, so I'll keep you posted

Many Regards,
Ad

OK I probably do not understand how to program a PIC while sitting in the Gateway, because after reading the link you put in your answer and severing the print trace as suggested,

You may be able to reprogram it in-circuit. Since low voltage programming has been disabled in the CONFIG bits, you will have to put a "high" voltage (13V) on the MCLR pin. That pin is connected to RB1, which won't like that. So you first have to sever that print trace. That's not really a problem because that connection isn't essential.

I still cannot program it using 13V connected to pin4 (MCLR) of the PIC. First i click on Program. After a while otmonitor says: 'Please manually reset...' Then i reset the gateway, connecting pin 4 to ground. After that, i apply 13V to pin 4. After 60 secs it says: 'Could not enter Self-Programming Mode', so that leaves me in doubt wether i am doing it right. Maybe i should be using MPLABX from Microchip's website to program it properly... I am still waiting for the PIC programmer to arrive but in the meantime it would be nice if this would work also.

Question: How can a PIC enter self programming mode when it is empty? or is it an integral part of the Microprocessor itself. Forgive me if i don't know this..

Regards,
Ad

There is a big difference between in-circuit programming and self-programming. In-circuit programming means that you connect a PIC programmer while the PIC is soldered onto the board. It only solves the problem of having to desolder the PIC. It cannot magically put the bootloader for self-programming into an empty PIC. You will still need a PIC programmer for that. Sorry if that wasn't clear.

My remark about severing the trace was just so that you don't blow up the PIC when you use a programmer to program the PIC in-circuit. Then you would still have to desolder it after all.

For in-circuit serial programming (ICSP), you would connect the PIC programmer to the JP1 and SV2 connectors of the OTGW as follows (standard ICSP connector pin numbers between parentheses):
Vss (3) -> JP1 1
Vpp (1) -> JP1 2
Vdd (2) -> SV2 1
PGD (4) -> SV2 2
PGC (5) -> SV2 3

Oh OK Now I get it. I presumed that i could use the USB->Serial cable to do the job. How wrong can one be..
I spend some time online to figure that out for myself now but i was not sure how to interpret the explanations of the thread(s) of the Forum.

This means good old patience before my PIC Programmer arrives and since i desoldered the PIC anyway and i put a IC-socket on the Gateway print, i will follow the normal procedure of programming it off the board. After that i can finally check the behavior of my Thermostat with the gateway using the Diagnostics patch .. pfft

Thank you for your answer Schelte,
Best Regards,
Ad