Help needed, Juno-G fault (not LCD)

[BustSkunk]

Having fixed the LCD on my brothers Juno -G it still has another fault.

Symptoms as follows:
Keyboard power is good.
LCD displays "Roland"
LCD displays and animates "Juno-G"
Display stops on "Juno-G". Keyswitch LEDs do not illuminate. Keys and controls do nothing.

I've scoped around the components on the processor board and everything looks OK. But there is no RS232 / MIDI to the other boards. Not sure if this is the fault or if this is a symptom. The processor is clearly getting stuck at or before this stage.

Does anyone have any suggestions please? I've looked for an RS232 debug terminal, but can't find one.

[bjaan]

Hi,

As it is stuck during the initialization phace it looks like the software is broken. I know that you can update (or also overwrite to reflash) the firmware on the keyboard by preparing a compact flash card with files you can get from Roland's website. I did that to update my firmware, maybe be executing this procedure you will fix/rewrite the software/firmware on the keyboard. It is at least a test of CPU and the flash rom.

What you could also try boot with just the mainboard (with CPU) and the display (LCD) connected to the jack board (which is providing power) (connection 4 in the wiring diagram on page 14 of the service notes) to see if boots then to see if the other boards are not causing an issue (short/wrong signal etc.).

My reference: I fixed a Elektribe EMX recently, by exchanging mainboard as there was an error on the LCD during the initialization (not blank LCD), the power was provided correctly (common fault is that FUSE1 is blown, which is providing the voltage to the CPU). The only way to fix it was to replace the mainboard with an entire other mainboard from another broken unit (and fix its FUSE1) to get a working unit, so I could only conclude that the software/flash/CPU was broken on the old mainboard. I didn't check any signals or so, just voltages going to the CPU.

Coming back to this it could just as well be that the flash chip with firmware has gone bad... OR that the capacitors C38 & C34 near the power input (next to the warm voltage regulator) have dried up and need to be replaced, make sure that you replace them anyway as they will fail at some point in the future (saw that in a youtube video, the sound would get unstable)

Next to IC13 on the panel-c board what looks like three switches and an indication (Normal vs Debug) could this be the area to hookup a debug console? It says CN14 (Serial and etc) for Connector 14 (CN14) in the wiring diagram. Even on page 32 it says GDB (which seems to be some debugger) next to CN14 and COMP_RXD, COMP_TXD & COMP_CTS & COMP_RTS . I am not sure how to use this. I found the following pointers on https://ftp.gnu.org/old-gnu/Manuals/gdb ... b_125.html The GDB remote serial protocol and sh-stub.c For Hitachi SH architectures.

What the stub can do for you

The debugging stub for your architecture supplies these three subroutines:

set_debug_traps
This routine arranges for handle_exception to run when your program stops. You must call this subroutine explicitly near the beginning of your program.

handle_exception
This is the central workhorse, but your program never calls it explicitly--the setup code arranges for handle_exception to run when a trap is triggered. handle_exception takes control when your program stops during execution (for example, on a breakpoint), and mediates communications with GDB on the host machine. This is where the communications protocol is implemented; handle_exception acts as the GDB representative on the target machine. It begins by sending summary information on the state of your program, then continues to execute, retrieving and transmitting any information GDB needs, until you execute a GDB command that makes your program resume; at that point, handle_exception returns control to your own code on the target machine.

breakpoint
Use this auxiliary subroutine to make your program contain a breakpoint. Depending on the particular situation, this may be the only way for GDB to get control. For instance, if your target machine has some sort of interrupt button, you won't need to call this; pressing the interrupt button transfers control to handle_exception---in effect, to GDB. On some machines, simply receiving characters on the serial port may also trigger a trap; again, in that situation, you don't need to call breakpoint from your own program--simply running `target remote' from the host GDB session gets control. Call breakpoint if none of these is true, or if you simply want to make certain your program stops at a predetermined point for the start of your debugging session.

Maybe you can catch an exception fault through the serial debugging session?

I hope this input helps you with resolving your issue

[BustSkunk]

Thanks bjaan.
A corrupted firmware image is what I suspect too.

Could you please clarify what happens in the following configuration...
Juno G mainboard is attached to the LCD.
Juno G mainboard is attached to Jackboard power (main board CN4)
Juno G mainboard is NOT attached to the Jack board audio (main board CN11 disconnected)
Juno G mainboard is NOT attached to the Panel C board (main board CN13 disconnected)

I get the following on the LCD
"Roland"
then "Juno-G" which spins once and stops.
The display freezes at this point.

I don't know if the mainboard is waiting for the processors on the other boards to communicate over the UARTs, if it has duff firmware, or if there is a fault on the mainboard.

Being able to rule out a fault on another board would help immensely.

I did spot SW5 & SW6 and the dev mode. There is some repurposing of UARTs, MIDI is dumped and UART2 beomes the debug interface. I agree that it looks like a GDB interface. I believe GDB to be an attachement to an IDE style code development tool. Without the source code on the IDE I think it would be damn near impossible to debug. I agree, it might be possible to snag an exception and hope it gives an associated buss address.

Why the developers ever chose not to squirt plain text out of a serial port as a processor boots is beyond me. Just hook up a terminal, and it read the last few messages...

I guess I will have to track down a PC card reader compatible with something newer than Windows 3.1!

[bjaan]

To update, I was using "Compact flash CF to PC card PCMCIA adapters" device and a 1 GB Compact Flash card, I got from eBay. And also a "USB 3.0 Card Reader Combo" card reader (from Amazon) that can read/write Compact Flash cards over USB3.0. This works fine under Windows 10.

See photo

PhotoCards.jpg (181.25 KiB) Viewed 1560 times

Also here is an update procedure https://www.cosmosmusic.com/upload/boar ... pdate3.txt

it mentions the JUNOGUPD.BIN file which is in the package you can download with the latest firmware.

When I open it starts with "KAR MI018 SysArc" and then with some file entries (it looks like a file system/archive):

SUBHEAD DIR ROLAND
SUBHEAD DIR ROLAND/SEQ
SUBHEAD DIR ROLAND/SEQ/SNG
SUBHEAD FILE ROLAND/SEQ/SNG/NUMBER.BIN
UBHEAD FILE ROLAND/SEQ/SNG/song0.svq
SUBHEAD FILE ROLAND/SEQ/SNG/song1.svq
SUBHEAD FILE ROLAND/SEQ/SNG/song2.svq
SUBHEAD FILE ROLAND/PNL/STARTUP.XMV
SUBHEAD FILE ROLAND/TCO.PRG

at the end it says JUNOG v200b189¦—ENDOFKARRl

/TCO.PRG says
Roland JUNOG application program�®)ŒLZ98L016���2008/12/25 13:06

Therefor it looks like it is not putting back not only the software but also some data files (the PNL, SEQ, SND folders are also part of the backup you can write to card)

The bytes following the TCO.PRG seem to be encoded, but one could reconstruct the binary to see what behavior occurs (using IDA or a similar disassembler)

I do not know anything about the impact of changing configurations, unless I open my keyboard (which is currently closed) the next time

[Leo Castro]

Hi, where did you get the firmware? Wich version of the display do you have?
There are 2 archives to update when you put the new display(2.01 firmware), the "BOOT" and the "PROGRAM".

Update the BOOT / PROGRAM
1. Update the BOOT
1-
2 Please copy the "Roland" folder in the "1 (BOOT)" folder to the Compact Flash
Card (or the PCMCIA PC Card).
1-
3
Please insert the Compact Flash Card (or the PCMCIA PC Card) above (1-2) to
the JUNO-G. And then please turn the power.
After no indication for about 5 seconds, the update starts automatically.
When message "Completed" appears in the screen, updating is completed.
Remove the memory card and turn off the power.
The update of the BOOT will finish in about 30 seconds.
If nothing is shown even after a minute or more, please turn off the power. And
also, please check the connection of the LCD UNIT is correct.
!Caution! : If you turn off the power before it is displayed as "Completed", its
JUNO-G will not start again. At this time, it is necessary to replace the
MainBoard.
2. Update the PROGRAM
2-
1 Please delete the all files stored in the Compact Flash Card (or the PCMCIA PC
Card) that was used above.
2-
3 Please copy the "Roland" folder in the "2(APLI)" folder to the Compact Flash
Card(or the PCMCIA PC Card).
2-
4
Please insert the Compact Flash Card (or the PCMCIA PC Card) above (2-3) to
the JUNO-G. And then please turn the power.
The update starts automatically.
When message "Completed" appears in the screen, updating is completed.
Remove the memory card and turn off and on the power.
3. Checking Version Number
Please check the version number on the TEST MODE.
PROG Ver.2.01
BOOT Ver.1.01

This is the update procedure when you install a new display. But be careful because if you have the old one, it will not work.

[bjaan]

I downloaded the JUNO-G SYSTEM VERSION 2.0 from Roland.com at https://www.roland.com/global/support/b ... a0fa25e9d/

2.0 is designed for the first version of the display, where 2.01 is for the second version of the display that Roland released later

As I am using the replacement display by dpeddi & bjaan, that is emulating (the display protocol of) the first version of display, I used 2.0

[Leo Castro]

Ahhhh ok, i’m sorry. I thought it was the original one.