Reading firmware out of a mask ROM microcontroller

[canadaboy25]

I connected everything up and probed the SCLK pin.  I found something that I had missed before.  On reset of the microcontroller, the SCLK pin is high and gets pulled low by the MCU shortly after.  This happens regardless of whether the CNVSS pin is high or low.  There is no activity on the SCLK pin after the initial change of state.

I tried grounding the SCLK pin and resetting the micro in case the pulse on reset was a detection pulse, but no change.  Still no response from the micro when trying to connect to it with the software.

Another interesting observation is that when the CNVSS pin is pulled high, the blue light on the front of the TV is on.  Without the CNVSS pin pulled high I could only ever get a red standby light.  When resetting the micro with the reset line, the blue LED goes out and then comes back on.  These LEDs are controlled directly by the micro so it is obviously changing modes when the CNVSS pin is pulled high.

Since the micro is pulling the SCLK line low, I would think this means it is not expecting a clock for synchronous communication as there would be two sources driving the same line.  I feel like I`m close as the micro is changing modes but I must still be missing something.

I assume I should be using the M16Cxx option in the software and not the M16C80/M32C option?

EDIT:  Looking through the pdf included in your github files that shows the connections for the programmer, it says P5_5(EPM) should be low.  According to the MCU datasheet this is pin 48 and according to the schematic for the TV, it is an input which is pulled high by a pullup resistor.  The line also runs to an unpopulated transistor for a fan failure alarm.  Perhaps this pin needs to be pulled low as well?  It just seems strange that Hitachi has included all of the other pins on the service connector but not this one.  If this seems important I will pull the board out and solder a wire to the MCU and try pulling it low.

[tru]

Interesting.

The P5_5(EPM) doesn't apply to your MCU because there is no EPM multiplexed on Port 5-5.
Most likely the equivalent to that is M1 which is pin 36, but you mentioned that it is already pulled low on the PCB.

Yes, the M16Cxx option is correct, which works for the MCU I read from (M30624FGPGP).

Perhaps this isn't your problem, but I did noticed that sometimes after powering the controller on and issuing the Get version command, sometimes it doesn't work, no response from the micro.  I have to retry by power it off and on a few times.

[tru]

Perhaps I've missed something and you have better luck, have a look at:

in the M306H5.pdf datasheet:

see page 302:
Figure 4.3.6. Pin Connections for Serial I/O Mode
Also, the following pages shows example serial circuits for serial mode 1 and mode 2.

see page 279:
Boot rom area (containing the bootloader), it mentions about CNVSS, P5_0 and M1.

Although it didn't work for me, try the official FlashStart program, a compiled version can be found in the Release folder:
https://drive.google.com/file/d/1cEjUK_z3p0rtq663KCi4mHj0KYs0C_Vf/view?usp=sharing

[canadaboy25]

Perhaps I've missed something and you have better luck, have a look at:

in the M306H5.pdf datasheet:

see page 302:
Figure 4.3.6. Pin Connections for Serial I/O Mode
Also, the following pages shows example serial circuits for serial mode 1 and mode 2.

see page 279:
Boot rom area (containing the bootloader), it mentions about CNVSS, P5_0 and M1.

Although it didn't work for me, try the official FlashStart program, a compiled version can be found in the Release folder:
https://drive.google.com/file/d/1cEjUK_z3p0rtq663KCi4mHj0KYs0C_Vf/view?usp=sharing

I took a look at the pages you indicated and it would seem that I have everything configured the way that they specify for the type 2 asynchronous communication.  I do not think it could be trying to use the synchronous mode 1 as the datasheet shows a pullup resistor on the SCLK input pin but my MCU is pulling that low.  So there would be no way to input a clock even if I wanted to.  The other thing that worries me is all of that information is in the flash ROM section of the datasheet.  Perhaps that means it does not apply to the mask ROM version.  After all, what is the use of a flash read/write interface on a chip that does not have a rewritable ROM?  Perhaps the serial interface on the flash/jig header is just a hangover from the development of the board when they were using a flash ROM version.

You mentioned a problem with the timing of the flash program on newer computers.  I have an old Pentium III system I could load Windows 2000 up on to try the original Flash Start program if you think that would be something worth trying.  I also could try a computer with a physical RS232 port and use some transistors to make a logic level shifter in case my USB to TTL converter is not interpreting the commands properly.  However, I don't think this is likely as I have used the converter for other projects and it has worked fine.  I can also see the data being sent to the MCU from the converter with my scope.

The other thing I could possibly try is removing the MCU from the board and just putting it on a temporary board with voltage supply and the crystal oscillator.  I wonder if the main board of the TV is interfering with an output of the micro if it is in flash mode.  Since the blue LED lights up when the CNVSS pin is high, the MCU must be setting some of its outputs high when it normally wouldn't.  Perhaps it is setting a pin to an output that is fighting with something else on the board and causing it to lock up?

The other thing that is in the back of my mind is the page of the datasheet that I attached in my original post.  "In the mask ROM version, contents of internal ROM cannot be read out when reseting the CNVSS pin with "H" input."  This definitely suggests it should be possible to read the contents of the mask ROM, however, they say the ROM cannot be read with the CNVSS pin high which contradicts everything else we have been doing.  This seems strange to me.

Let me know what you think.
Thanks for all the help so far!

[tru]

You mentioned a problem with the timing of the flash program on newer computers.  I have an old Pentium III system I could load Windows 2000 up on to try the original Flash Start program if you think that would be something worth trying.  I also could try a computer with a physical RS232 port and use some transistors to make a logic level shifter in case my USB to TTL converter is not interpreting the commands properly.  However, I don't think this is likely as I have used the converter for other projects and it has worked fine.  I can also see the data being sent to the MCU from the converter with my scope.

The other thing I could possibly try is removing the MCU from the board and just putting it on a temporary board with voltage supply and the crystal oscillator.  I wonder if the main board of the TV is interfering with an output of the micro if it is in flash mode.  Since the blue LED lights up when the CNVSS pin is high, the MCU must be setting some of its outputs high when it normally wouldn't.  Perhaps it is setting a pin to an output that is fighting with something else on the board and causing it to lock up?

The other thing that is in the back of my mind is the page of the datasheet that I attached in my original post.  "In the mask ROM version, contents of internal ROM cannot be read out when reseting the CNVSS pin with "H" input."  This definitely suggests it should be possible to read the contents of the mask ROM, however, they say the ROM cannot be read with the CNVSS pin high which contradicts everything else we have been doing.  This seems strange to me.

Let me know what you think.
Thanks for all the help so far!

The timing problem only happens for a few tries (quite rare), it generally works most of the time, I don't think an old system will help.  I think your point about the flash/jig being left over from when they used the flash version of the chip sounds about right.

The section about not being about to read out internal ROM is referring to the Microprocessor mode (function as CPU with no internal ROM or RAM, i.e. the addresses are remapped to external bus) vs Single processor mode (MCU mode with ROM and RAM, not remapped)

Man, they have a round about way of describing things, the title gives some evidence of my reasoning: Precautions for External Bus = Precautions for Microprocessor mode

Also further evidence is in the text:
"...In the flash memory version, contents of internal ROM cannot be read out when resetting the CNVSS pin and the M1 pin with "H" input", which refers to flash version set to microprocessor mode, and obviously in that mode it cannot read out ROM or RAM since the addresses are remapped to external bus.

I've just noticed something in the datasheet (page 11, Table 1.5.3 Pin Description), it says for mask ROM version, connect M1 pin to VSS or VDD2, that suggests M1 is ignored, so perhaps cannot be put into bootloader mode anyway?

[bson]

Check the 9-pin D sub interfaces/inputs/drivers.  Those connectors were (are?) used for proprietary remote control in mid/high end AV equipment, so say a Toshiba AV receiver could turn on/off the TV, or other basic control.  The TV might think there's something plugged in and that it's under remote control if something on the interface isn't working right.  It may or may not be an actual RS-232 port, and if it's not while someone applied actual RS-232 signalling to it, well that could explain why it's dead if that's the problem.

[canadaboy25]

The timing problem only happens for a few tries (quite rare), it generally works most of the time, I don't think an old system will help.  I think your point about the flash/jig being left over from when they used the flash version of the chip sounds about right.

The section about not being about to read out internal ROM is referring to the Microprocessor mode (function as CPU with no internal ROM or RAM, i.e. the addresses are remapped to external bus) vs Single processor mode (MCU mode with ROM and RAM, not remapped)

Man, they have a round about way of describing things, the title gives some evidence of my reasoning: Precautions for External Bus = Precautions for Microprocessor mode

Also further evidence is in the text:
"...In the flash memory version, contents of internal ROM cannot be read out when resetting the CNVSS pin and the M1 pin with "H" input", which refers to flash version set to microprocessor mode, and obviously in that mode it cannot read out ROM or RAM since the addresses are remapped to external bus.

I've just noticed something in the datasheet (page 11, Table 1.5.3 Pin Description), it says for mask ROM version, connect M1 pin to VSS or VDD2, that suggests M1 is ignored, so perhaps cannot be put into bootloader mode anyway?

Yeah, this datasheet is definitely not the clearest one I have seen before.  They talk about different modes and pins but do not give a concrete description of what they are or how they work.

It is definitely looking like this chip does not have the serial bootloader interface built in.  I have probed the MCU's Tx pin with my scope while sending it commands from the software and never received any activity from it at all.  It would make sense that they wouldn't include the bootloader in the mask ROM version as they would never be able to modify anything anyways, and by the time they were producing the mask ROM, they likely would've had everything the way they wanted it for production.

Sort of a shame because I had the Rensas documents with all of the machine codes for this MCU ready to decode the firmware if I could get it out.

The enable signal I am missing is generated by an Altera CPLD.  The power button on the TV connects directly to the Renesas MCU.  So the MCU has to send some sort of signal out to the CPLD for it to activate the other PSU enable line.  The only communication lines the MCU has with the rest of the system is one UART interface and a "SlowBus" interface, whatever that is.  I would think the MCU is seeing something it doesn't like as it never turns on the blue power LED when the power button is pressed.  I have no idea what a "SlowBus" interface is so that one would likely be tricky to analyze.

I'm not sure what half of the connections to the MCU are even for.  A lot of them seem to lead to unpopulated connectors on the PCB which I suppose may have been for different models.  I don't think the MCU is damaged as it still does perform some functions such as outputting the watchdog clock when the CNVSS pin is low

Check the 9-pin D sub interfaces/inputs/drivers.  Those connectors were (are?) used for proprietary remote control in mid/high end AV equipment, so say a Toshiba AV receiver could turn on/off the TV, or other basic control.  The TV might think there's something plugged in and that it's under remote control if something on the interface isn't working right.  It may or may not be an actual RS-232 port, and if it's not while someone applied actual RS-232 signalling to it, well that could explain why it's dead if that's the problem.

I wondered that as well.  It is a proper RS-232 port as it has a dedicated driver chip and I found the protocol description in a pdf I posted previously.  However, it doesn't seem like there is any way for the MCU to detect something being plugged in as there is only the 4 UART signal lines going to the driver chip.  I also think I read somewhere that the TV will revert back to the standard operation mode after power is removed.

[tru]

Ouch, I've made a few mistakes regarding the Microprocessor mode.

I'm not sure if this is worth doing or looking into, but perhaps when bored and with lots of free time...

Correction: The Microprocessor mode doesn't remap RAM or registers, it only remaps the internal ROM/FLASH address range, and also enables the reserved address range.

You made me go and look into the Renesas bootloader disassembly code again.  Good news, it appears that boot mode (bootloader mode) is really just Microprocessor mode + the EPM or M1 pin (in your case) is simply used to switch (bank) in the boot rom area (containing the bootloader), the bootloader code is then in the same memory address as the internal ROM so it can run.  As a further protection, Renesas prevents the processor mode from being changed when code is run in this address range, but it copies itself into RAM and jumps execution to RAM address 0x600 which is then able to switch processor mode.

The bootloader disassembly shows that it does indeed rewrite the PM0 and PM1 (processor mode select registers) back into Single processor mode!!  There also appears some secret code stuff in there, modifying reserved address.

It sounds possible that we can wire up the MCU for Microprocessor mode, i.e. pins: D0 to D15 (16 bits data bus), and pins: A0 to A19 (address bus), and connect to a suitable parallel FLASH memory chip with the bootloader stored on it!  Hopefully it should run the same way as boot mode.

[canadaboy25]

That sounds promising!  In microprocessor mode with an external memory we can make it load up whatever code we want it to.  The function of it copying code to RAM and executing from address 0x600 is definitely an interesting behavior.

Sounds like it would take a lot of tinkering, but I am up for the challenge.  I am much too interested about what is in the ROM to let it keep its secrets without a fight.

Since we would have to wire up the data and address buses, it seems like I will have to remove the chip from the board and make a test board to mount it on.  Otherwise, I would have to remove a bunch of the Hitachi logic board components to free up all of those pins.  Seems like a good move though as it will remove any unknowns from the test setup because there won't be anything else connected that could possibly interfere with the chip.

I have a CNC mill and blank PCB material so I would be able to quite easily make up a test board to mount the chip on and be able to hook up anything else we wanted to it.  I'm sure I have a flash chip on some junk board somewhere that would work for the project as the ROM on my chip is only 128K.

I also have an Altera DE2-115 FPGA development board that we could use to implement a flash chip and any other functions we may need.  The FPGA board has a header with exactly 36 GPIO pins on it so we could just hook the data and address buses from the MCU directly to it.  Perhaps this could be easier than reading and writing flash chips.

If I were to leave the chip on the board, I would have to remove 6 transistors, and 9 resistors and then run 36 mod wires to an external mod board.  I am not sure which will be less work.  I definitely like the idea of putting the MCU on a custom made testing board as it would provide the best connections and remove the rest of the logic board circuitry from the equation, but I am slightly worried about overheating of the chip while removing it just because it is pretty large.

Let me know what your thoughts are.  Definitely looking forward to the challenge though!

[tru]

Cool!

I have the same thoughts!  Yep, removing such a big chip is risky but I think that may give less problems than modifying the existing PCB.  I do have a controller with a broken display that has Renesas M30624FGPGP on it that I can try this on (doesn't matter if I break it), but I don't have any FLASH chip on hand at the moment, nor do I have any experience on building such a circuit with external FLASH memory + MCU and because it would need the minimum supporting stuff like oscillator, capacitors, etc.

For anyone interested in the reverse engineering, I attach link of the bootloader V4.04 that I extracted from the M30624FGPGP:
https://drive.google.com/file/d/1vXizFkau_73ImZyE0IEJnIaVDyKl-Id-/view?usp=sharing

The .asm file is the interesting file and I've partly commented the good parts.  I'm too lazy to go through every line of code in there.
The other 2 files are the raw dumps: .mot (motorola srecord format) and .bin (binary format).

[canadaboy25]

Yeah it is a tough call.  Looking through the schematic it seems possible to isolate every line of the MCU from the rest of the system except for the Vcc and GND pins as they are hardwired on the PCB with no series resistors.  I can even isolate the MCU's power rail from the rest of the system by removing a 0 ohm link to prevent the rest of the board from being powered.

I will go through the schematic and map out all of the pins that are connected to Vcc and GND and see if they are going to be a problem for what we want to do.  If they won't cause a problem I will probably go with the option of removing all the series resistors and adding mod wires to break out the MCU pins to a header PCB.  I have a large spool of 38AWG enamel coated magnet wire which works really good for that sort of thing.  This seems like the safest option as I would never stop kicking myself if I killed the chip while removing it.  And even if I removed it successfully, it would have to be soldered down to my custom PCB, removed again, and then resoldered to the original board.  That is a lot of heat/cool cycles for this old thing.  Leaving it on the original board also lets us take advantage of the support circuitry that is already present such as the oscillator and some capacitors.

I will also have a dig though some of my junk to see what flash chips I have around.  When reading though the Renesas datasheet I realized my FPGA board does not have enough pins for all 36 bus data lines and the required control signals.  So perhaps I will have to make up a little board to solder a flash chip to.

I will also spend some time looking through the bootloader you uploaded.  Very interesting stuff!

[canadaboy25]

After going through the schematic, it looks like all of the I/O pins should be able to be isolated from the logic board without removing the chip itself.

I've been reading through the datasheet for the Renesas MCU but I can't seem to find where it shows the reset vector.  I see in your disassembly file that you have 0xFF020 listed as the reset vector.  How did you determine that was the reset vector?  Did you find it listed somewhere or did you determine that from the code?

I am trying to understand how we can know where the MCU will start executing code from in the flash memory if we are using microprocessor mode.  Also, since the address and data buses can operate in multiplexed or separate bus mode, how do you know which one will be used when the MCU resets in microprocessor mode?

Perhaps I am missing it in the datasheet, but I have not seen it anywhere.

[tru]

After going through the schematic, it looks like all of the I/O pins should be able to be isolated from the logic board without removing the chip itself.

I've been reading through the datasheet for the Renesas MCU but I can't seem to find where it shows the reset vector.  I see in your disassembly file that you have 0xFF020 listed as the reset vector.  How did you determine that was the reset vector?  Did you find it listed somewhere or did you determine that from the code?

I am trying to understand how we can know where the MCU will start executing code from in the flash memory if we are using microprocessor mode.  Also, since the address and data buses can operate in multiplexed or separate bus mode, how do you know which one will be used when the MCU resets in microprocessor mode?

Perhaps I am missing it in the datasheet, but I have not seen it anywhere.

You're right the reset vector address is not fixed, and is determined from a fixed location, and in this case at the end of the code, see page 62, Table 2.7.1. Fixed Vector Tables.

The reset vector address is stored as the low 20 bits at addresses 0x0FFFFC to 0x0FFFFF (low byte ordering), if you open the .bin file and go to the end you will see the last hex values are:
20 F0 0F FF, reversed byte ordering gives:
FF 0F F0 20, and the low 20 bits gives:
0F F0 20

The BYTE pin sets the external bus width:
low for 16 bit data bus
high for 8 bit data bus
Single chip works only in 16 bit data bus so best we pull it low

I'm not sure about the multiplexing, hmm still looking at the datasheet.

[canadaboy25]

You're right the reset vector address is not fixed, and is determined from a fixed location, and in this case at the end of the code, see page 62, Table 2.7.1. Fixed Vector Tables.

The reset vector address is stored as the low 20 bits at addresses 0x0FFFFC to 0x0FFFFF (low byte ordering), if you open the .bin file and go to the end you will see the last hex values are:
20 F0 0F FF, reversed byte ordering gives:
FF 0F F0 20, and the low 20 bits gives:
0F F0 20

The BYTE pin sets the external bus width:
low for 16 bit data bus
high for 8 bit data bus
Single chip works only in 16 bit data bus so best we pull it low

I'm not sure about the multiplexing, hmm still looking at the datasheet.

Ahh, that's how it works.  Makes sense!  I figured it had to be something like that but couldn't quite see it.

I think I may have found something about the multiplexed bus.  On page 24 it shows the Processor Mode 0 (PM0) register.  It shows the reset values for the register if the CNVSS pin is high or low.  In both cases the 5th and 6th bits are 0 which means the bus is in separate bus mode.

I'm just not sure how the bus would be changed to multiplexed bus mode as you would have to modify the bits in the control register but to do that you would have to run some code from flash.

[tru]

Ah, I see so is set by software, I was looking at the pins!
You're right, since the reset values is separate bus we can just leave as is, so the data bus is separate from the address bus, which is easier to work with I think.
Yes to change it to multiplex bus you would set them inside your code.

[tru]

Ops, I see what you mean, if you need to run code to set them for multiplex mode, your circuit needs to start from separate bus mode, that's crazy!

[tru]

In the bootloader code, something still puzzles me, near the start there is a loop that checks whether port 8 pin 5 (pin P8-5) is pulled high, nothing is mentioned about that in the documents, or perhaps I've made a mistake and it's not port 8, hmm.   I think we will need to disable that anyway.

[canadaboy25]

Ops, I see what you mean, if you need to run code to set them for multiplex mode, your circuit needs to start from separate bus mode, that's crazy!

Yeah, that's what I was wondering about.  Definitely doesn't seem like the most efficient setup!  Would've thought an external pin to set the bus mode seemed more logical.

I was going to get started removing some of the series resistors and running wires to a breakout board.  Looking at the physical board, some of the pins are frustratingly close to other pads and vias which will make running wires quite difficult as the bare part of the wire may want to touch these points after soldering.  Now I'm back to contemplating removing the entire chip.  I have removed and replaced larger chips with the annoying thermal pad underneath without issue.  This one should be easier as it has no thermal pad and the PCB pads will have a low thermal mass so it should come off pretty easy.

I think I'm just going to try and remove it unless I can think of a better idea.

In the bootloader code, something still puzzles me, near the start there is a loop that checks whether port 8 pin 5 (pin P8-5) is pulled high, nothing is mentioned about that in the documents, or perhaps I've made a mistake and it's not port 8, hmm.   I think we will need to disable that anyway.

Hmm, interesting.  The part you have labelled as "doing secret stuff" where it writes to a "do not use" memory address is also very interesting.  It seems there are a few hidden features that they do not want people knowing about.  Or perhaps it is generic code that was used on different chip families and that is just a leftover that they did not remove or change.  Quite strange.

[tru]

Just discovered that P8_5 is shared with NMI, so the code is actually checking NMI, and this makes sense now.  NMI is normally connected to a pull-up resistor.

Good point, the secret stuff may be just left over code.

[canadaboy25]

Just discovered that P8_5 is shared with NMI, so the code is actually checking NMI, and this makes sense now.  NMI is normally connected to a pull-up resistor.

Good point, the secret stuff may be just left over code.

That definitely makes sense.  P8_5 is connected to a pullup resistor but a CPLD on the board can pull it low to signal an interrupt.

I was about to pull the MCU off the board and my hot air station burned out.  Quite the timing.  While I've been waiting for a new one I've been looking through the bootloader code.

It's interesting to see the code on such a low level and notice the places the compiler could have done better optimization.  Such as places where two values are compared, then a jump if equal instruction that jumps two lines down, which is followed by a jump instruction to somewhere else in the case of not equal.  Instead there could've been a jump if not equal instruction and the second jump could've been omitted.  Such as at address 0xFF08C.  Unless I'm missing something.

Everything has more or less made sense except for one thing.  At address 0xFF094, the value at 0x600[A0] is moved to R0L, R0L is moved to address 0x3BE, the value at 0x601[A0] is moved to R0L, R0L is then again moved to address 0x3BE.  The first two instructions seem to be redundant as the value at 0x3BE is overwritten without being used.  I must be missing something as I can't imagine why those instructions would be there if they aren't serving any purpose.  Any idea what's going on there?

[tru]

Everything has more or less made sense except for one thing.  At address 0xFF094, the value at 0x600[A0] is moved to R0L, R0L is moved to address 0x3BE, the value at 0x601[A0] is moved to R0L, R0L is then again moved to address 0x3BE.  The first two instructions seem to be redundant as the value at 0x3BE is overwritten without being used.  I must be missing something as I can't imagine why those instructions would be there if they aren't serving any purpose.  Any idea what's going on there?

You're right, also a lot of the code is duplicated, first half for synchronous mode 1 and second half with similar code for asynchronous mode 2, and no effort to merge the common parts together.

I forgot to link the M16C/60 series group that is relevant for the M30624FGPGP where the bootloader came from:

Hardware Manual - contains Special Function Registers (SFR, memory mapped registers), memory map, vector table, pinouts, etc:
http://www.symmetron.ru/suppliers/renesas/pdf/rej09b0185_16c62pthm.pdf

Software Manual = contains MCU machine instructions:
https://www.renesas.com/eu/en/document/man/m16c60-m16c20-m16ctiny-series-software-manual?language=en

The destination address 0x03BE is a memory mapped register (SFR), data byte input to the in-built hardware CRC calculator, see page 15 of hardware manual.
The bootloader pushes the two values into the CRC calculator which automatically updates a CRC result.

Code: [Select]

FF094 72C00006 MOV.B:G 0600H[A0],R0L  ;MOV byte at address (0600h + A0) to R0L register. A0 = 0000h (I didn't see where it is set so is default reset value I guess) this becomes MOV byte at 0600h to R0L register
FF098 03BE03 MOV.B:S R0L,03BEH  ;MOV ROL to CRC calculator (03BEh = SFR to CRC data input)
FF09B 72C00106 MOV.B:G 0601H[A0],R0L  ;MOV byte at address (0601h + A0) to R0L register. A0 = 0000h this becomes MOV byte at 0601h to R0L register
FF09F 03BE03 MOV.B:S R0L,03BEH  ;MOV ROL to CRC calculator (03BEh = SFR to CRC data input)
Something unrelated, with some instructions there is a size specifier and format type, e.g.:
MOV.B:G

The MOV instruction syntax is as follows:
MOV.size(:format) src,dest

You can see that there is a size specifier and a format type.

In the above example:
.B = size specifier meaning MOV byte
:G = General format

For more information see the software manual.  Specifically see page 52 of software manual, "3.1 Guide to This Chapter".

[canadaboy25]

Ah, I completely forgot to check where that address actually lead to.  I just assumed it was a RAM address.  Thanks for clearing that up.

I have the software manual but I didn't have the hardware manual.  Looks like lots of interesting stuff in there.

Also, in the code snippet you posted, I believe A0 would have the value 0x6FD as there is a jump to subroutine instruction at 0xFF91 which jumps to the block you have labelled as Part 4: Calculate CRC.

One more question, what disassembler did you use to generate the assembly?

I suppose I should also order some flash chips while I wait for my hot air station.

[tru]

I used the official (evaluation version) compiler/debugger called "High-performance Embedded Workshop" (HEW):
https://www.renesas.com/us/en/software-tool/evaluation-software-tools

Go down to section:
C/C++ Compiler Package for RX Family
(for High-performance Embedded Workshop)

To download you need to register an account - I registered with some bogus information 

The evaluation version is crippled so that "Save Assembly Text..." can only output a limited length, so if you want to save disassembly out to a file you will have to manually enter start and end address (of limited length) and repeat.  Then merge the files together into one.  I've already done this with the bootloader, but if you need to do for other code.

The debugger requires the SEGGER simulator driver to be installed but doesn't seem to be included, however Microchip MPLAB X v5.30 (not sure about latest version) does include it so if you install that first then install HEW, the debug menu will be available, and you can then step into the disassembly, view addresses, e.g. RAM, etc.

To save you fiddling with the IDE I'll upload the HEW project file with the bootloader added to the project.
https://drive.google.com/file/d/1XTvn-dG0XC1l06mifZUPhTah52_6QtVq/view?usp=sharing

Btw, anyone has a full version of HEW?

[canadaboy25]

Hi, sorry for the long absence from the project, I've been very busy lately.

I have done a bit of work on this since my last post.  I have purchased an FPGA board with enough I/O pins to connect up all the bus address and data line signals and also the control lines.  I think the FPGA will be the easiest solution since it will be very simple to configure it as a simple flash memory.  I did look for dedicated chips, but finding a 5V flash memory with the correct parallel bus sizes and control lines was very difficult.  I have also decided to remove the MCU from the board.  I am in the process of designing a PCB to mount it on and implement the plan.

In the meantime, I got my hands on a broken 60" LED TV.  All it does is blink an error code for the backlights.  I have tested all the backlight strings and they are all fine.  I have also probed the signals coming to the backlight inverter board from the main board and there is nothing at all.  So there is no way the main board would even be able to know if the backlights are defective and I suspect there is a problem on the main board.

The main board is controlled by a Renesas M16C-R5F364A6N MCU.  I figured I may as well try and dump the firmware from it since it is a flash version instead of mask ROM.  However, I must be doing something wrong as I cannot connect to this one either.

There is a debug header beside the chip that exposes pins 7,29,30,31,32,33,34,39 of the MCU.  Pins 29 and 30 are TXD1 and RXD1 while pins 33 and 34 are TXD0 and RXD0.  Pin 7 is the CNVSS pin.  The datasheet for this MCU is not near as comprehensive as the other one, but I was not able to find any reference to an M1 pin anywhere so I suppose this chip does not have one.

I used a logic level converter to connect my 5V UART to USB converter to the MCU since it runs off 3.3V.  I pulled CNVSS high, powered on the MCU, and tried both the RX0/TX0 and RX1/TX1 lines but never got any response.  Probing the RX line of the MCU I can see a nice clear 3.3V signal getting to the chip, but the chip never transmits anything in response.

I must be doing something wrong or missing something since this is a bit different MCU than the last one.  I find it strange how little information there is about programming these chips or I am not looking in the right place.

Any ideas on what I am missing here?

I will post back when I get the other MCU mounted on a PCB breakout board and connected up to the FPGA.

[tru]

I agree, their documentation is all over the place!

That M16C-R5F364A6N MCU doesn't have the M1 pin, instead it uses EPM pin (pin 39) which I guess serves a similar purpose - and that needs connecting to low.

Have you also checked the CE (pin 44) is high and the CLK1 (pin 31) is low?

These are the details:

To enter Single-chip boot (loader) mode in serial I/O asynchronous mode:
CNVSS = VCC1 (high) = PIN7
P5_5/EPM = VSS (low) = PIN39
RESET = VSS to VCC1 (low then high) = PIN10
P5_0/CE = VCC2 (high) = PIN44
P6_5/CLK1 = VSS (low) = PIN31
P6_7/TXD1 = (TTL) serial out = PIN29
P6_6/RXD1 = (TTL) serial in = PIN30

Power (note: it is best to power on the TV and let itself supply the voltage - no need to inject any power):
VSS = ground
VCC1 = 3 to 5V
VCC2 = 3 to 5V
*VCC1 >= VCC2 or simply apply same voltage.

Documents can be downloaded from here:
https://www.renesas.com/us/en/products/microcontrollers-microprocessors/other-mcus-mpus/m16c-family-mcus-r32c-m32c-m16c/m16c64a-16-bit-microcomputers-non-promotion

Hardware manual:
https://www.renesas.com/eu/en/document/man/m16c64a-group-users-manual-hardware?language=en

Pages of interest (Hardware manual):
Page 41 = Pinout of chip
Page 51 = Memory map (Single-Chip Mode)
Page 728 = Setting of Standard Serial I/O Mode 2