culfw@ARM

[chapelhill]

Hi thanks for the quick response.

I have tried with build 151 and the previous build, it seems to make no difference. Are there any other builds to try, all the other builds appear to be too early for this development. I presume the problem is with the bootloader?

Which pins can I connect a resistor to, too see if I can resolve with hardware pull up resistor and approx what resistor value?

Board has
ST1
1x 2x 3x 4x
ST2
1x 2x 3x 4x

My cube was bought early this year, but has lost its settings twice, so I want to convert to using the CUL FW since I need functionality for switching heating on and off based on radiator demand. It is marked with the TRX868-TI and has AT91SAM7X256 ARM chip.

Regards
Chapelhill.

[Telekatz]

The resistor has to be connected between pin 1 and 3 on ST2. Use a 10k resistor.

Did you also try to use the bootloader from build 151?

[chapelhill]

Just to confirm.
I have retried with bootloader from build 151 and build 138 and no difference.
I did a file compare between bootloader from those two builds and it did not find any difference.

I have tried with 10k resistor between pins 1 and 3 on ST2 debug connections.
It made no difference.
Checking with a volt meter on dc voltage it showed both pin 1 and pin 3 at 3.3v without the resistor anyway.

Perhaps there is a problem with my cube?

I have tried with minicom on raspberry pi and this is the output. I think it is also aware that the connection drops before completing transfer.
Interestingly when connected to pi, the D1 led goes to constant on after 7 seconds, but returns to flashing at 3 times per second once minicom connection is established.

         +-----------[xmodem upload - Press CTRL-C to quit]------------+
         |Sending CUBE_BL.bin, 618 blocks: Give your local XMODEM recei|
         |ve command now.                                                                          |
         |Xmodem sectors/kbytes sent: 618/77kRetry 0: No ACK on EOT   |
         |                                                                                                       |
         |Transfer incomplete                                                                        |
         |                                                                                                       |
         | READY: press any key to continue...                                             |
         +-------------------------------------------------------------+


Chapelhill

[Telekatz]

I then start up the teraterm software.
Connect to the port
File > Transfer > XMODEM > Send
Select the bin file from the dialogue and it start writing ok, but progress window seems to disappear before it finishes entirely (about half way), and you hear the USB disconnect and re-connect notification.
The light D1 is still flashing at about 3 times per second.

If I disconnect and re-connect the power the D1 led is still flashing at 3 times per second.
I think that means the Firmware flash has not worked.

Check the switch on the bottom of the cube. Normaly after a firmware is loaded on a empty cube, the bootloader jumps direct to the firmware after power on. Even if the firmware upload fails.
Pressing the switch while power on the cube activates the bootloader. This is indicated with the fast flashing of D1. If the switch is always closed, the bootloader is always active.

[chapelhill]

Hi I have checked the switch and that seems ok.

I was searching the net for other images of the circuit board and I noticed that mine has the ARM Atmel AT91SSAM7X256 not the AT91SSAM7X512
The version number written on my circuit board is 1113596J and not 1113596H

I presume we might need some different settings in firmware for the differing Atmel chips as they have differing amount of memory and ram.

Is there any other information I can provide?

[chapelhill]

Hi I have checked the switch and that seems ok.

I was searching the net for other images of the circuit board and I noticed that mine has the ARM Atmel AT91SAM7X256 not the AT91SAM7X512
The version number written on my circuit board is 1113596J and not 1113596H

I presume we might need some different settings in firmware for the differing Atmel chips as they have differing amount of memory and ram.

Is there any other information I can provide?

[Telekatz]

Hi I have checked the switch and that seems ok.

Did you also measure the level of the input? You can measure it on MP8 and it should be pulled up to +3.3V.

I was searching the net for other images of the circuit board and I noticed that mine has the ARM Atmel AT91SSAM7X256 not the AT91SSAM7X512
The version number written on my circuit board is 1113596J and not 1113596H

The firmware is intended to run on the AT91SAM7X256.

Attached you can find a version of the firmware you can flash with SAM-BA direct to the cube without the need of a bootloader. The flash procedure is the same as for bootloader_CUBE.bin.

[chapelhill]

Hi all.

I have checked MP8 and it shows 3.3 volts normally, and drops to 0 volts when the switch is pressed, returning back to 3.3v on release of the switch.

I have loaded the firmware you attached and flashed with SAM-BA and upon reboot we have D3 on continuously D2 off and D1 flashing slowly approximately once every two seconds. That is with the cube connected to usb only, no ethernet connection.

Looks like it has succesfully flashed firmware and booted normally.

I will see if I can work out how to use the device and update the thread accordingly.

Many thanks for the patience you have shown me.

Regards
Chapelhill.

[Telekatz]

Hat jemand von euch die a-culfw auf einem Cube mit der Version 1113596J installiert und kann bestätigen, dass das Flashen mit dem Bootloader normal funktioniert? Ich hab hier auch nur welche mit der Version 1113596H.

[Joachim]

Moin Telekatz,
Ich kann Dir bestätigen, dass die a-culfw auf einem CUBE mit der Version 1113596J nicht funktioniert.
Das angepasste file von Heute um 17:30:04 funktioniert einwandfrei.

Insgesamt habe ich bisher 2 CUBE's (die älter als 3 Jahre sind erfolgreich geflasht, und den mit der Version 1113596J nur über das von Dir angehängte.

Gruß Joachim

[Telekatz]

Hallo Joachim,

Hast du den Cube mit der Version 1113596J als Bausatz gekauft und eine Anleitung mit Schaltplan dazu bekommen? Mich würde interessieren, ob der Taster TA2 bei dieser Version noch am Pin 22 (PA14) angeschlossen ist, oder ob dieser Pin jetzt auf Masse liegt. Der Bootloader verwendet ein Low Signal an diesem Pin, um den Bootloader Modus zu aktivieren. Ansonsten wird die Firmware gestartet, die im Flash nach dem Bootloader geschrieben ist.

Das File von Heute ist im Prinzip die gleiche Version wie die für den Bootloader. Der einzige Unterschied ist, das es an den Anfang des Flashs geladen wird und dann direkt startet.

Gruß
Alex

[Joachim]

Moin Telekatz,
Ich habe den CUBE nicht als Bausatz gekauft, und damit leider auch keinen Schaltplan.
Der CUBE, mit dem das Flashen geklappt hat, ist Version 1113596I und hat einen at91sam7x512 an Board.
Ich habe hier beide geöffnet neben mir stehen. sag mir was ich suchen oder messen soll, und ich mache es.
Pin 22 (PA14) finde ich leider nicht.

Gruß Joachim

[Telekatz]

Könntest du bitte je ein Foto von beiden Platinenseiten der Version 1113596J machen, auf denen man die Leiterbahnen erkennen kann?

[Joachim]

Bitteschön

[Telekatz]

Der Anschluss von TA2 sieht genauso aus wie bei mir. Das scheint es wohl nicht zu sein.

Du könntest mal folgendes probieren:
-Flash erase mit J1 durchführen.
-In SAM-BA bootloader_CUBE.bin auswählen und auf Send File klicken.
-In SAM-BA die Address von 0x100000 auf 0x104000 ändern
-In SAM-BA CUBE_BL.bin auswählen und auf Send File klicken.
-Script Boot from Flash ausführen.
-USB trennen und Cube neu starten.

Wenn die a-culfw jetzt normal startet, liegt das Problem wohl an der Flash Funktion im Bootloader. Startet hingegen direkt der Bootloader, funktioniert anscheinend die Erkennung, ob bereits eine Firmware geladen wurde im Bootloader nicht.