SCI boot mode doesn't work on S7G2-SK

hello,
I am trying to program the S7G2-SK by using the boot mode with SCI9, but I receive the next message : "Error(E4000003): A timeout error occurred.Operation failed." I am using a FTDI cable to convert USB to RS232. I set the md pin to 0 and I made a reset of the MCU.
I guess I am doing something wrong but I don't know what. Someone can help me, please?

  • Boot mode is only entered if the reset line is asserted, so set MD pin low (J1 in position 2-3), then assert the reset by shorting the RESET jumper J2 briefly. The S7G2 does also support USB as well as UART for boot mode, I would suggest trying USB boot mode as well. First make sure the latest version of RFP is installed (this will install the USB driver for Synergy USB boot), then if the J5 of the S7-SK board is connected to the PC (the user USB connector), then the device should show up as "Synergy USB Boot (COMxx)" in device manager:-

     

  • In reply to Jeremy:

    Thank you Jeremy. I already program the S7G2-SK by using USB Boot and it works well. I correctly set MD pin with the jumper (position 2-3). In device manager, I see "Synergy USB Boot" when I use USB Boot and with SCI Boot, in device manager I see "USB Serial port". I am using RFP V3.03.00. I read RFP user's manual and in the section error messages, it is written to check bit rate and clock settings. But on the other hand, in the S7G2 user's manual I see "When the MCU is activated in boot mode, the embedded program for serial programming is executed. This program automatically adjusts the bit rate of the SCI ". Also, in the section error messages of RFP user's manual, it is indicated the communication may doesn't work if we are using USB-to-serial converter, do you have any idea why ?
  • In reply to Marie:

    I don't know the full reason for the comment in the RFP manual:-

    "Remark Good communications may not be possible if you are using a USB-to-serial converter, a self-made cable, a
    self-made extension cable, or the like for connection with a tool."

    But it looks like to me it is trying say that if a cable is used that is of low quality, and introduces noise, that boot mode might not work.
  • In reply to Jeremy:

    From my experience, I can say that with the same cable some usb->rs232 adapters are not reliable with high baudrates (> 115 kbauds) but some others can manage baudrates up to 921 kbauds without error.

  • In reply to TLHQ:

    There is also the issue that in factory mode, the initial baud rate is 9600 and the RFP tool will send a baud rate change command and negotiate a higher baud rate. Some USB to serial adapters may not support this.
  • A standard USB-RS232 Cable will not work, you need a "USB-UART" or "USB-Serial TTL" cable for 3.3V.
    On the S7 the SCI9 pins for boot mode are on SCI9_B, P109 and P110. On the SK-Board they are connected to the JTAG-Connector, with 100k pullups, P109 is connected to U11 also. This may causes problems too, even with the right cable.
  • In reply to josh222:

    OK. Thanks for yours answers ! I take note of your comments and if I am successful in getting it to work, I will keep you informed. Thanks again.
  • In reply to Marie:

    I looked at the SK-Schematic again and there seems to be a way to use the on-board RS232 driver chip (which may introduce an additional pronblem, I wrote somethimg about a HW-mod some time ago in this forum:
    renesasrulz.com/.../19856
    Besides the metioned connections, P109 & P110 are connected to J20 also and TXD-RS232 & RXD-RS232 on the S7-side of the RS232 driver chip are available on J9. So you can try to use a standard USB-RS232 cable, connect it to CON6, make the following connections with jumper wires: J20.24 to J9.1, J20.26 to J9.2.
    But I doubt it will work reliably without the hardware modification at the ICL3227.
  • In reply to josh222:

    Hi !
    Monday, I finally succeded to program the SK_S7G2. It wasn't difficult, just connect the right wire to the right connector... Actually, I used an external MAX3232 which convert RS232 to TTL, in order to bypass the on-board ICL3227.