Can the RCM3209 on Prototype board, and the 20-101-1183 programming cable stay on

Question

Can the RCM3209 on Prototype board, and the 20-101-1183 programming cable stay on the RCM3209 after being loaded with a program from either the compiler or the RFU? I have noticed the embedded program does not seem to run until the programming cable is removed and the board is reset. I would like to keep it connected. And reload new builds as needed.

Also, does the prototype board have a debugging connector? I need to see if the RCM3209 is still running or dead.

Answer 1

You should be able to run the program right from the debugger while is attached and debugger is running. If you close the debugger it will stop the program running on the debugger, you will need to disconnect the cable to set the board in run mode.

Answer 2

From the compiler, you can hit F9 to start running the program from within the debugger after compiling it to the board.

The prototype board doesn't have a debugging connector -- you use the 10-pin programming header on the RCM3209 to program the core module and debug it. You can switch to the DIAG header to monitor STDOUT when running outside of the debugger. Take a look at Samples/STDIO_SERIAL.C for how to route debug output over serial port A when running outside of the debugger.

As for running the program after downloading code with RFU, it is possible to send a serial sequence to have the program start, but it's not an option in the RFU program.

The OpenRabbit project (https://github.com/spth/OpenRabbit) actually has an RFU replacement for Linux that can start the program automatically after loading it. You could look at that source for the sequence (IIRC it resets the board via DTR and then sends three bytes at 2400 bps).

Comments

Thanks.  This is interesting, but am not sure I understand completely...

  "You can switch to the PROG header to monitor STDOUT when running outside of the debugger. Take a look at Samples/STDIO_SERIAL.C for how to route debug output over serial port A when running outside of the debugger."

I have not yet looked at the Sample you mentioned.  This sounds like it would be the only way to see if any debug is being provided if, MAYBE, the original BIN files I have were built with debug?

What do you think?

---

Correct, if you're expecting output from the old .BIN file, it would only work if you had that feature enabled at compile time.

And I meant, "...switch to the DIAG header..."  Sorry for the error.

---

thanks... so when you say to:

    "...switch to the DIAG header..."

I can move the cable connector from PROG which was used to load the program, to DIAG to see if any debug messages are being sent by STDOUT? will the DC9.62 compiler app see this output? What window would be opened to display it? Just the 'Stdio window' under Windows > Debug Windows > Stdio ??

Also, one of the strange differences between the old saved BIN files that work, and the new builds of the BIN files is how many differences there are between them.

One in particular is that there are about 135 lines of code are compiled above this one readable portion. This readable portion is on line 2 in the working old saved BIN files, but line 137 in the recent builds of the original source code:

    DynamiCUniversal Rabbit BIOS Version 9.50;

Also, I suppose this BIOS version 9.50 is different and unrelated to the compiler version 9.62?

Thanks

matt

---

Look at a hex dump of the binaries or use a hex editor.  Doing a "diff" on the binaries as if they are text files will be a big mess.  "Beyond Compare" for Windows has a good binary/hex "diff" interface.

If you have a different "Rabbit BIOS Version", then it was compiled with a different version of Dynamic C.  Unfortunately, the BIOS version didn't always change with each Dynamic C release.  So DC 9.62 will show BIOS 9.50 in its binaries.

As for the DIAG header, you need to enable that feature using macros as shown in STDIO_SERIAL.C.  You need to use a terminal emulator (such as Tera Term) and the correct baud rate on that serial port to interact with the board outside of Dynamic C.