CAN and bluetooth issues

[Lidenburg]

I couldn't get the CMD response from the RN52 when trying to program it so the RN52 isn't programmed, but I decided to try it out anyway as i figured it would still work partially atleast.

I plugged it into my 03 9-5, and the power LED came on and the BT1 and BT2 LEDs started blinking (seemed like they were both blinking at the same time, not sequentially) then went into the car and double pressed the CD/RDM button and it seemed like the car could see the bluesaab and communicate with it, but holding down the SEEK button until the first beep, I couldn't see the RN52 from my phone.

Then a while after swapping between different audio sources, the car stopped seeing the bluesaab and double pressing the CD button only started playing the normal CD. The CAN led stopped blinking at this points aswell.

I've looked after shorted pins on the chip but can't seem to find any (feel free to check: http://imgur.com/a/4jSCL)

Also: the bluetooth leds are only blinking the way described for a while, then they stop blinking completely, then start again. Not sure if it should be doing that?


Any idea what's going on or what's wrong?

[Seth]

Karlis may have to chime in here, but I'll try first.

If the CMD doesn't show up, then I would guess there's a com port speed mismatch, or the CMD pin isn't being pulled low (?). By default, the rn52 talks at 115200, and I see you've shorted the 9600 baud, so you may have to undo that short, talk to the device at 115200, set it to 9600, power down, short the 9600 pads, power on, see if that works...

Both bt1 & bt 2 leds should not be blinking simultaneously; that means it's in DFU mode (3 blinks). If they blink together a bunch...i'm not sure. The leds should blink alternately, indicating it's ready to pair with a device (it should be discoverable).

I didn't see any shorts...so I would assume it's a software thing (i like to blame software since I'm a hardware guy ;)

You got the atmega328 with a bootloader, or burned your own bootloader? The 328 has the latest bluesaab software installed? It will tell you if you connect an FTDI connector and open serial monitor.

Please report back what you find; we'll try to help sort it out.

[Lidenburg]

I've tried switching the baud rate to 115200 and 9600 multiple times, neither worked. I then read about shorting those pins and tried again (I've tried both baud rates, neither work).

The DIP switch is set to normal.

I burned the bootloader myself and I used the latest version from github when I plugged it in today.


I know that the code is being run succesfully, as I added some debug output in the (RN52 programming) code to see what data was being sent and what branches were being taken.

[Seth]

Can you verify that you have the right capacitor on C1? It looks like you have a diode there...if so, I bet the voltage regulator isn't working right. Also, C2 doesn't look like it's fully soldered down; might wanna add some flux and touch up those pins again.

Lemme know what you find.

[Lidenburg]

Comparing these two images: First, Second. It seems like it's the right capacitor?

I'll try fixing up C2 tomorrow. If that doesn't do it your guess is the voltage regulator? Looking at it now it looks like maybe the smaller middle pin on the voltage regulator isn't 100%, guess I'll try fixing up that tomorrow aswell.

[Seth]

Ok, it looks right, sorry :)

Hmm. I'm not sure why you're having issues. Karlis said he would chime in when he gets time.

Step 1 is gonna be, be able to talk to rn52.
Step 2 will be, make sure rn52 has the right settings.

Have you tried the RN52 PRG? It's got some extreme basics to where you can just talk to the rn52 (I'm guessing you've done this; the normal program won't give you a CMD prompt).

[Karlis]

Sorry it took me a while... Here are my two cents:

1. First things first, we need to determine which BT LEDs (and in what fashion) are blinking. If they blink alternatively that means RN52 is in discoverable mode and it should show up in phones Bluetooth settings. If only one (blue) LED is blinking, that means RN52 is in connectable/non-discoverable mode. With the latest code on Github, I've enabled "1-6" button control on IHU. Since you own a 9-3, you would have to hold button SEEK+ on IHU. This will force RN52 to go into discoverable mode. SEEK long press in the middle till beep works only on 9-5s.

2. In order to check RN52 settings and reprogram it, you will need to upload RN52-BT-PRG code (link in "Software" section) to the module. Since you are running everything on v3.3 PCB, please do short the 9600 pins. That will save you a lot of headache. Once the code is uploaded and terminal is opened @ 9600 baudrate, you should see two messages: "RN52 programming mode" and "CMD". Now RN52 is ready to accept commands. Type "V" (without quotes) and you should get the version of firmware on RN52. It should be 1.16. If it is less than that, you might want to upload newest firmware on RN52 using Microchips DFU utility (basically a simple "Click", "Click" -> "Next", "Next", "OK", "Done" MS Windows application).

3. CAN comms with the car - I believe one of CAN LEDs is flashing. Though it's doing it so fast, that sometimes even I myself wonder if I have CAN comms in place or what... :). What text are you seeing on the SID? One more thing to try would be to remove whatever CD you currently have in the unit and give it another test. Yeah, I know it sounds silly, but worth trying.

[Lidenburg]

First of all I have a 9-5 not a 9-3.

1. The red and blue BT led were blinking at the same time (atleast from what i could tell).

2. I've been using the "RN52-BT-PRG" program for trying to communicate with the RN52, the problem like I said is that it doesn't show "CMD", or rather, the RN52 doesn't seem to be sending any data back. I added some debug code to see every byte the RN52 sends back and it mostly sends back 0's (bytes with value 0x0 that is), very rarely it will send something else.

3. I believe the SID said "CD 1 play", or something like that. The weirdest thing is that the car could see it for a while, and then it stopped seeing it and the CAN led stopped blinking, which makes me think the led is not just blinking really fast.

[Seth]

I think you can try this:
Remove the 328.
Power the board from a power supply, and using only the RX and TX lines of an FTDI interface, attach the RX/TX lines to the UART rx/tx lines.

This way you can power everything, and talk directly to the rn52. You'll need a way to ground the CMD pin to force the rn52 into command mode since the 328 won't be there to do that for you. You can just jumper  the digital pin 4 on 328 (physical pin 6) to ground to do that.

[homerisback]

Hi,
To avoid a new thread, I feed this one with a RN52 issue.
I have a v3.3 module that has been working well for a short time and now it behaves strangely.
I suspect a faulty RN52 because :
- at power up, it goes discoverable and connects to a phone
- music starts playing for more or less 30 seconds and then, it seems that RN52 goes to sleep. BT leds go off and nothing happens if I don't recycle power or reboot RN52 in CMD mode.

* I tested it with various revs of the CDC code, ending with the latest one available on Github, no change.
* I tested it in CMD mode with Atmega328 removed (as RN52 can connect & play music in that mode as well), no change.
* I did a factory reset of RN52, then reboot ; tested it on factory config, no change
* I updated it with the suggested parameters from here, no change
* While in CMD mode, I thought about an intermittent power loss but as the RN52 goes in that kind of "sleep mode", it keeps responding to terminal commands and I can reboot it from here, so it still is under power.
* I spammed the "Q" command and at once, it goes from 040D (connected and playing) to 0000 (disconnected). It never ever goes back to discoverable.
* I checked the "autosleep delai" parameter which is at 0 (not activated).

Is anyone here has a better idea to submit for further testing ? I think I'll have to switch to a brand new RN52 (damn desoldering work to expect ), maybe it has been damaged...

[Seth]

Those are all great troubleshooting steps. Do you have a multimeter? I would check that the 3.3v is really 3.3v...it almost sounds like the rn52 isn't getting enough power.

I think these are the same symptoms I've had before and I *think* I had a wrong diode on the output of the vreg so it wasn't getting the full voltage.

Although, on the 3.3a pcbs, I think they used a 3.6v regulator...but still check to make sure the 3.3v rail is actually getting that.

[homerisback]

I initially thought about a complete lack of power but when I saw the RN52 responding to commands, I assumed that power was good... and forgot to check it !
I'll do that once back home, thanks for this answer and crossing fingers to find one diode faulty instead of RN52 ;)

[Seth]

I just thought of another troubleshooting step you could try before removing the rn52; have you tried reflashing the rn52 firmware yet? Not sure if it would help or not but can't hurt. And since you've done all those steps before, you might as well resort to putting ALL the settings back and the latest software. 

On Mon, Jan 9, 2017 at 10:33 homerisback [via BlueSaab Forum] <[hidden email]> wrote:

I initially thought about a complete lack of power but when I saw the RN52 responding to commands, I assumed that power was good... and forgot to check it !


I'll do that once back home, thanks for this answer and crossing fingers to find one diode faulty instead of RN52 ;)

If you reply to this email, your message will be added to the discussion below:

http://bluesaab-forum.2349123.n4.nabble.com/CAN-and-bluetooth-issues-tp540p916.html

To start a new topic under Hardware, email [hidden email]


To unsubscribe from Hardware, click here.


NAML

[homerisback]

Yes I thought about it, but not yet performed. Will try it after power check...

[homerisback]

Hi,
I did the power check and everything looks fine when hooked to the car : a beautiful and steady 3,35V at check pads and at RN52 pins !  When powered with my arduino uno board, tension was not over 2,8V, explaining the cut after a short while...
I decided to keep it hooked and drive to work (45 min trip) : everything worked flawlessly, including reconnection after a short stop. I'm happy but don't understand anything. I suspect a dry soldering somewhere but on my trip I went on a very bumpy road and no failure occured.
Actually, it was a module I sold to someone who reported the failure and when I got it back for replacement, it refused to start in my car, kind of confirmation that it was faulty. Without time to look closer at it, I left it on my desk's corner and eventually came back to it recently. Now it works without any fixing unless the software update and factory reset previously performed.

I'll retrofit it and my v4.2 with the THS4522 v1.2 AMP...
Anyway, thanks Seth for your answers !