Self programming mode

[nextdomo]

Hello,

I have a few questions, I hope there is someone who can help me.

I'm trying to set the OTGW in his self programming mode. I did this by sending a break condition with a host processor (TX of host low for 1.5 ms).

The documentation states that the OTGW responds with a <ETX> but I did not receive this so I'm not sure if successfully set the OTGW in his self programming mode.
I've tested it with fw version 3.4 as well with 4.0b4.

This is what happens:
3.4
- Host send BREAK to OTGW
- After circa 60 ms OTGW sends a <EOT> (0x04) to host

4.0b4
- Host send BREAK to OTGW
- After circa 20 ms OTGW sends a "Op" string to host (what does "Op" mean? Couldn't find it anywhere in documentation)
- After circa 80 ms OTGW sends a <EOT> (0x04) to host
- From this point on the "Op" string is transmitted frequently from OTGW to host

I have also try to capture the <ETX> on startup (using the reset pins) but had the same effect I only saw a <EOT>.

Another thing is I did noticed is that the OTGW is in a mode where it sends a lot of 'random' strings after startup (or reset).
This happens in both firmware versions and those strings are e.g. :
- "T10181885"
- "BD0010A00"
- "B40304611"

I have to send a "PS=1" command (with the host processor)to stop this mode, also I can't use the otmonitor tool while the OTWG is in this mode.
What is is this? Is there something i have overlooked?

So to sum up my questions
- Is the OTGW set correctly in his self programming mode?
- What does the respond status "Op" mean?
- In what mode does the OTGW send several 'random' strings and what do those strings mean?

Thanks in advance for the answers,

Jordi

[hvxl]

Microchip Application Note AN851 defines <ETX> as 04h. If you prefer to call that character <EOT> that's fine, as long as you understand they're the same thing (and 04h is just a different way to represent 0x04). So the gateway is sending the expected character.

When the gateway resets, it transmits the string "OpenTherm Gateway 4.0b4", or whatever version you use. "Op" are the first two letters of that. I'm not sure why it starts resending the banner string before actually resetting. I have never noticed that with my own gateway.

The other strings you mentioned are not "random strings". They are the opentherm messages, as explained in the reports paragraph on the web site. What the messages mean is described in the opentherm specification. The otmonitor tool will translate them into readable form.

What do you mean you "can't use the otmonitor tool while the OTWG is in this mode"?

[nextdomo]

Hi,

Thank you for the reply, I was in the understanding that the data should be requested with the command and totally overlooked the part of documentation where is told about the unsolicited reports, sorry for that.

I have looked some more into the issue where the OTGW sends the "Op" string continuously. Found out that this is the same reason that the otmonitor tool doesn't 'work'.

This happens in FW version 4.04b.
I used a terminal (TeraTerm) to debug the data.

In this mode the OTGW sends a "Op" string every 1 second continuously, and no other data then the "Op" string is send by OTGW.

The OTGW will enter this mode after it received an UART break, the break is in this case 1500 us long.
(for the otmonitor tool I use a USB cable as virtual COMport which probably causes some static when I plug in it in, I can imagine that this is seen by the OTGW as a 'break')

If I send any character (using my terminal) to the OTGW it stops this mode and it boots again and works as expected, this also applies to otmonitor which now will read the unsolicited reports and translates them to readable.

A printout of my terminal:

ttotfgw.png (36.46 KiB) Viewed 5914 times

[hvxl]

The only way I can come up with that could explain that situation occurring is if the serial line doesn't go all the way up after a break (i.e. stays below 4.5V), until you send a character.

As I have also concluded from another thread, my current attempt to handle a continuous BREAK state on the serial line apparently isn't good enough. I am going to have to devise a better way.

[nextdomo]

Hi,

I continued working on the self programming of the firmware, this is what I do during the update:

1. After powerup wait for ETX
2. When ETX is received by host request version of PIC (cmd=0)
3. When version is received by host request EEdata of PIC (cmd=4)
4. When EEdata is received by host write flash blocks to PIC
4.1 First erase flash row (cmd=3) (len=1)
4.2 Second write flash block (cmd=2) (len=8)
4.3 Third read flash bytes to verify (cmd=1) (len=32)
Note that I skip the adresses 0x0000 - 0x0100 because of bootloader area
5. When flash update is done, write EEdata (stored at step 3) to PIC (cmd=5)
6. Force a reset the PIC to enter bootloader again.

But unfortunataly I wasn't able to do a succesfull update yet. This is what happened.
- When bootloader is entered again after a update the PIC chip continuously sends the value 0xFF for circa 15 seconds long.
- After 15 seconds it stops sending the 0xFF string and it looks likes it is working now.
- But when I force a reset again there is a string of data which I assumed was the OTGW version string but there were strictly 0x00 values in that string

Any ideas what I might be doing wrong? Is the updating part correct and maybe, for some reason, the new image was corrupted? And is the bootloader area correct? (I based it on the datasheet, I use a PIC16).

Thanks in advance.

[hvxl]

The bootloader area is not at 0x0000 - 0x0100. This is one of the changes to the algorithm of AN851 as explained in selfprog.asm:

Code: Select all

;########################################################################
; Self programming, based on Microchip AN851
;########################################################################
; This code has been optimized for size so it would fit in 0x100 code words.
; To achieve this, some special tricks had to be used. As a result the code
; may be a little hard to read
;
; The functionality differs from that described in AN851 in the following
; respects:
; 1. No auto baud detection. Communication must take place at 9600 baud.
; 2. Dropped the first <STX> that was used for auto baud detection.
; 3. Dropped the third address byte as it would always be 0.
; 4. The code does not check the last byte of EEPROM data memory to enter boot
;    mode. Instead it transmits a <ETX> character and waits up to 1 second for
;    a <STX> character.
; 5. The code is designed to be placed in the highest part of memory. That way
;    it doesn't interfere with the interrupt code address. It does rely on the
;    main program to call the self-program code at an appropriate time.
; 6. Due to the location of the boot loader code, it cannot be protected using
;    the code protection bits in the configuration word. This means that the
;    boot loader code can also be updated, if necessary.
; 7. The Erase Flash command has been implemented for the PIC16F device.
; 8. The device reset command is 0x08, not any command with a 0 length.
; 9. The version command can be called with a data length of 1-3 words. It will
;    report the following information:
;    1. Version
;    2. Boot loader start address
;    3. Boot loader end address
;    The software used to reflash the device can use the last two pieces of
;    information to determine which part of memory should not be touched.