JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

Remote bricked after connecting to the wrong JP1 interface ?
Goto page Previous  1, 2
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Hardware
View previous topic :: View next topic  
Author Message
unclemiltie
Expert


Joined: 21 Jan 2004
Posts: 1730
Location: Pittsburgh, PA

PostPosted: Mon Nov 20, 2017 12:48 pm    Post subject: Reply with quote

dude wrote:
mdavej wrote:
Yep. Works fine. Here's how to connect:
http://www.hifi-remote.com/forums/viewtopic.php?p=127948#127948
Thanks for the link. That is helpful! That looks solely as UART/serial mode... which might be ok (not sure yet) but I suspect the need will be more in a bit-bang mode. Thoughts?

Before I jump down this rabbit hole... I should ask, has anyone already done this? (written an entire flash recovery program targeted at say jp1.4 remotes?) If there is anything already out there anyone is aware of (short of multi thousand dollar hardware programmers/debuggers) it would be great to know. I've not seen anything open source or mentioned but my Google searches may have just been slack.

I don't know of anyone who has done it and we do know of a number of people who have bricked their JP1.3 remotes and suspect that the remote somehow got into tool mode.

Might be an interesting experiment although given that you can buy a new remote for $20 not sure that the time investment is worth it for the small number of remotes that you would "fix"
_________________
this JP1 stuff is a sickness!
Back to top
View user's profile Send private message
digital_silence



Joined: 22 May 2004
Posts: 237

PostPosted: Sun Jan 07, 2018 7:03 pm    Post subject: Reply with quote

unclemiltie, you are definitely right wrt the value for effort. However, that would make a good learning exercise for those who want to see how it's all done.
So, the H/W and low-level protocol are clear. The biggest problem I can see now is where to get the BIN image to flash into the remote. It possibly can be read from the other remote of the same model, but the PDF document specifically outlines the "Read Protection" mode in which (I quote):
"Once Read protection is enabled, it can only be disabled by performing a Chip Erase."
I would be surprised if the OFA did not execute that option to prevent reading of their code from the uCU.

But if anyone has such BIN dump for Comcast URC1067Bx3 , I'd be prepared to give it a try.
Back to top
View user's profile Send private message
unclemiltie
Expert


Joined: 21 Jan 2004
Posts: 1730
Location: Pittsburgh, PA

PostPosted: Mon Jan 08, 2018 3:17 pm    Post subject: Re: S3 Tool Mode Programming Reply with quote

dude wrote:
I *think* this is what you are looking for...
https://static.arantius.com/misc/S3%20Embedded%20Flash%20Serial%20Programming.pdf

It describes Tool Mode programming for the S3 / SAM8 protocol.

Let me know if this is helpful or I am off base. :D


yea, that looks like it. I finally got a chance to read it and it's definitely the details on how tool mode works on the S3 SAM8 processors.


If you can figure out how to put the device into Tool mode and write the flash that could open up a bunch of possibilities, one of which is fixing bricked remotes (at least the JP1.3 S3F80 ones)

Definitely following this thread!
_________________
this JP1 stuff is a sickness!
Back to top
View user's profile Send private message
digital_silence



Joined: 22 May 2004
Posts: 237

PostPosted: Tue Jan 09, 2018 11:11 pm    Post subject: Reply with quote

dude wrote:
That looks solely as UART/serial mode... which might be ok (not sure yet) but I suspect the need will be more in a bit-bang mode. Thoughts?
I may be wrong here, but it looks to me like there might be a bit of a confusion here between the two communication channels.

1) The JP1 channel is used to program the EEPROM inside the remote via Serial or I2C pins of the micro used in that remote. For that communication, you HAVE to have a flash program code (aka firmware) already loaded into the micro. JP1 communication can not re-program the micro and can not erase its program code (at least in theory)

2) The "ReFlashing" channel (described in your PDF document) is used to (re)program the micro (load the program code into its flash memory). It uses the hard-coded routines inside the micro's h/w, and therefore does not require any previously loaded firmware to operate (i.e. can program a completely blank micro). It requires a micro to be put in a special mode (often referred to as "programming") by holding designated pin(s) high or low during the power-up (see my post on the previous page)

In general, those two channels are using DIFFERENT pins of the micro, so I assume, the JP1 connector can NOT (generally) be used for ReFlashing.

Note also that Re-Flashing protocol (2) described in your PDF document is NOT a UART/serial mode as you assumed, but is rather some proprietary protocol, similar to I2C, but not quite the same. Also, hardware-wise, it takes a bit more than just a bit-bashing, as the data pin is bi-directional, and the DATA pin of the programming host will have to be changing direction between output and input.

Happy to be corrected by JP1 experts here.
Back to top
View user's profile Send private message
unclemiltie
Expert


Joined: 21 Jan 2004
Posts: 1730
Location: Pittsburgh, PA

PostPosted: Wed Jan 10, 2018 8:18 am    Post subject: Reply with quote

My take was that since we suspect that we somehow got the remotes into tool mode with the JP1.3 interface that there was a way to refresh. But yes, someone would have to take a look to make sure that the pins on the interface were the right ones.

One of the hardware experts could figure this out. Is Tommy Tyler still playing with JP1 stuff?
_________________
this JP1 stuff is a sickness!
Back to top
View user's profile Send private message
binky123
Expert


Joined: 14 Feb 2004
Posts: 1226

PostPosted: Wed Jan 10, 2018 12:57 pm    Post subject: Reply with quote

So IDC-5 pin for JP1 is used for nRESET. The IDC-5 pin on a JP1.3 remote also goes to Pin 9 on S3F80 and can put chip into TOOL mode. Hence, it is recommended to not connect this pin when connecting to a JP1.3 remote.

I recall something about dangling wires also causing the S3F80 to go into TOOL mode as well.

It definitely looks doable to put the chip into TOOL mode using a special cable with IDC-5 connected.
Back to top
View user's profile Send private message
binky123
Expert


Joined: 14 Feb 2004
Posts: 1226

PostPosted: Wed Jan 10, 2018 1:04 pm    Post subject: Reply with quote

Another thought is to reprogram the PIC controller on the JP1.3--JP1 dongle to put the JP1.3 remote into TOOL mode.
Back to top
View user's profile Send private message
unclemiltie
Expert


Joined: 21 Jan 2004
Posts: 1730
Location: Pittsburgh, PA

PostPosted: Wed Jan 10, 2018 3:46 pm    Post subject: Reply with quote

binky123 wrote:
So IDC-5 pin for JP1 is used for nRESET. The IDC-5 pin on a JP1.3 remote also goes to Pin 9 on S3F80 and can put chip into TOOL mode. Hence, it is recommended to not connect this pin when connecting to a JP1.3 remote.

I recall something about dangling wires also causing the S3F80 to go into TOOL mode as well.

It definitely looks doable to put the chip into TOOL mode using a special cable with IDC-5 connected.


But are the serial in/out bits the same in the JP1.3 mode and tool mode? IIRC the serial is done with one of the parallel IO ports on the SAM8 and it's really not a I2C interface but something that must be clocked properly for things to work
_________________
this JP1 stuff is a sickness!
Back to top
View user's profile Send private message
binky123
Expert


Joined: 14 Feb 2004
Posts: 1226

PostPosted: Wed Jan 10, 2018 7:28 pm    Post subject: Reply with quote

Yes, the pins are the correct ones for JP1.3 and TOOL mode.

Quote:

P3.0 is SDAT.
P3.1 is SCLK.

3 P3.0/T0PWM/T0CAP/SDAT -- IDC-4 Rx RE3.0
4 P3.1/REM/SCLK -- IDC-6 Tx RE3.1
5 Vdd(+3v) -- IDC-1 V+
6 Vss(GND) -- IDC-3 GND
9 TEST -- IDC-5 +3v for TOOL mode for programming(use V+ from IDC-1).(in JP1 was nReset).


This is how some bytes are scrambled as it interprets SDAT/SCLK changes as valid commands.

So changing I2C Start and Stop doesn't seem too difficult.
Back to top
View user's profile Send private message
binky123
Expert


Joined: 14 Feb 2004
Posts: 1226

PostPosted: Wed Jan 10, 2018 8:16 pm    Post subject: Reply with quote

The S3 Flash programming protocol uses inverted Start and Stop conditions, that is:
- Start condition SCLK = VDD, rising edge on SDAT
- Stop condition SCLK = VDD, falling edge on SDAT

I looked at libRemoteIf.pas file
original
Quote:

// This procedure sends a "start" condition to the EEPROM. This is done by
// changing SDA's state from 1 to 0 while SCL is 1. We then set SCL to 0 in
// preparation for sending and receiving data.
procedure Start;
begin
OutPort(FiPortWriteAddr, FiOutBoth); // SDA=1, SCL=1
Delay(2);
OutPort(FiPortWriteAddr, FiOutSCL); // SDA=0, SCL=1
Delay(5);
OutPort(FiPortWriteAddr, FiOutNone); // SDA=0, SCL=0
Delay(2);
end;

// This procedure sends a "stop" condition to the EEPROM. This is done by
// changing SDA's state from 0 to 1 while SCL is 1. We make sure that SDA
// and SCL are both 0 when we start in order to guarantee that the transitions
// occur in the correct order.
procedure Stop;
begin
OutPort(FiPortWriteAddr, FiOutNone); // SDA=0, SCL=0
Delay(2);
OutPort(FiPortWriteAddr, FiOutSCL); // SDA=0, SCL=1
Delay(5);
OutPort(FiPortWriteAddr, FiOutBoth); // SDA=1, SCL=1
Delay(2);
end;

so for S3 Start and stop are now
Quote:

// This procedure sends a "start" condition to the S3. This is done by
// changing SDA's state from 0 to 1 while SCL is 1. We then set SCL to 0 in
// preparation for sending and receiving data.
procedure Start;
begin
OutPort(FiPortWriteAddr, FiOutNone); // SDA=0, SCL=0
Delay(2);
OutPort(FiPortWriteAddr, FiOutSCL); // SDA=0, SCL=1
Delay(2);
OutPort(FiPortWriteAddr, FiOutBoth); // SDA=1, SCL=1
Delay(5);
OutPort(FiPortWriteAddr, FiOutSDA); // SDA=1, SCL=0
Delay(2);
end;

// This procedure sends a "stop" condition to the S3. This is done by
// changing SDA's state from 1 to 0 while SCL is 1. We make sure that SDA
// and SCL are both 0 when we start in order to guarantee that the transitions
// occur in the correct order.
procedure Stop;
begin
OutPort(FiPortWriteAddr, FiOutNone); // SDA=0, SCL=0
Delay(2);
OutPort(FiPortWriteAddr, FiOutSDA); // SDA=1, SCL=0
Delay(2);
OutPort(FiPortWriteAddr, FiOutBoth); // SDA=1, SCL=1
Delay(5);
OutPort(FiPortWriteAddr, FiOutSCL); // SDA=0, SCL=1
Delay(2);
end;
Back to top
View user's profile Send private message
unclemiltie
Expert


Joined: 21 Jan 2004
Posts: 1730
Location: Pittsburgh, PA

PostPosted: Wed Jan 10, 2018 8:23 pm    Post subject: Reply with quote

binky123 wrote:
Yes, the pins are the correct ones for JP1.3 and TOOL mode.



Cool, so this might work to unbrick some remotes
_________________
this JP1 stuff is a sickness!
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Hardware All times are GMT - 5 Hours
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Get Smart! the band's official homepage Rockabilly Central