Quantcast
Channel: RN52 firmware update
Viewing all 49 articles
Browse latest View live

Re: RN52 firmware update (bmalbuck)

$
0
0
@MadMatt any luck getting 1.10 updated to 1.16? I have the RN52-I/RM variant chip with 1.10 and have tried to update DFU over USB with no such luck. The module is just not recognized over USB as if there is no driver. Chip enters DFU mode but utility can't find it. Positive I have it hooked up correctly - Chip enters DFU mode but not found by utility.
 
If anyone has any tips please let me know. I absolutely need 1.16.

Re: RN52 firmware update (Ronnimbl)

$
0
0
Well if you use Windows 7 the DFU updater prolly wont work.
I had to upgrade the FW over Windows 8, using the SPP-port.
 If you find a way to upgrade FW using a COM-Port instead of a SPP-Port let me know ^^

Re: RN52 firmware update (bmalbuck)

$
0
0
UPDATE: I now understand SPP is serial port profile now supported in Windows 8+. This would allow serial port communication with the module assuming it has this profile enabled. But still, how would one pair and use SPP while in DFU mode. Still a mystery as to how FW update would be performed.
 
Thanks for the information @Ronnimbl.
 
I created a new Windows 8.1 virtual machine (vmware fusion running on my MacPro notebook), got the DFU Utility up  and running but still can not get Windows to discover the RN52 module over USB. I tried UART method on a COM port to no avail.
 
Could you explain how you were able to upgrade FW using SPP (assume this is standard parallel port ? LPT) What hardware is involved? I only have USB and thunderbolt ports. I'd greatly appreciate a detailed setup you performed to get FW upgraded over SPP-port.

Re: RN52 firmware update (mightymac)

$
0
0
***Solution***
All,
 
I was having the same problems upgrading my RN52-i/R110 over UART from v1.10 to v1.16. I contacted support and opened a ticket. (See full answer below) The short answer I received is that in V1.10 the ability to upgrade firmware over UART is not available so you are stuck unless you can upgrade over USB. My RN52 is on a breakout board and I don't have an Evaluation Kit. The support tech suggested to try and connect via USB. So I connected to the 'USB - and the USB+' and try to upload the firmware over USB. (Of course using the proper firmware). He couldn't guarantee success, but my project needs these features so I decided to try it.
It worked!
 
So I have a simple list of my steps below what I did.
 
 
I am using Windows 7 x64. I have a RN52-1/RN110 breakout board from Sparkfun
 
1. Cut USB cable I had and strip the wires. I did not use the 5V that is coming from the USB cable to drive GPIO3 high. (In the documentation is describes using a voltage divider). So just make sure you drive GPIO3 high on 3.3v.
 
2. I previously soldered headers on my breakout board so I am connecting to my device through a breadboard. Connect the USB+ from the cable to the USB+ of the chip and do the same for the USB-. In my usb cable case green was USB+ and white was USB-. You will want to double check that before continuing. I put the USB to the shared ground I was using for everything else.
 
3. Downloaded the proper firmware and re-ran the installer and made sure I installed the USB drivers.
 
4. Booted up the device in DFU mode. Windows recognized the device and installed the drivers for the device.
 
5. Ran the utility following the instructions making sure to choose install over USB.
 
6. One thing to note when it was upgrading the firmware it said something like attempting to boot the device in DFU mode and the green and red lights turned off. I thought the device shut off so I pushed my power button on and the device came on then it shut off. Finally I noticed that windows was installing another driver it was 'CSR driver in DFU mode' or something like that. (a second driver from when I plugged in the device) So when the device shuts off I would not keep turning it back on and I would check to see if windows is looking for a driver. Also Windows takes FOREVER trying to install the driver so I made sure to hit 'Don't look with Windows update for the driver' and it installed the driver really quick.
 
7. Followed the instructions on the screen and it uploaded great.
 
8. Another thing to note. at the end of the upgrade it said attempting to to boot device in run-time mode. It hung on there for a while and I was thinking that GPIO3 was still HIGH so I took the voltage off of GPIO3 and rebooted the device. The installer said it failed, but it booted fine and I can get into CMD mode via UART the new version is V1.16 and I can use the new features
 
I hope this helps and I will respond to questions, because I know how frustrated I was in trying to upgrade the firmware. Also I didn't really proofread this post (time to watch a movie with the wife :) ) so I am sorry for any grammar mistakes. Let me know if this worked for you guys.
 
Regards,
MightyMac
 
 
---------------------------------------------------------------------------
Support ticket from Microchip
 
Problem Resolution:
Hello,

It was good talking with you this afternoon.

I informed you that it wasn't possible to upgrade firmware over UART in v1.10. This is a new feature that was added in v1.16. To upgrade from v1.10 to v1.16, you'll need to use the USB pins, and select USB in the upgrade utility. You mentioned that you were using a breakout board, which didn't have USB implemented. I said it might work to solder wires to the USB pins in order to add a USB connector. I have seen customers with issues doing this in the past. USB requires clean signals for proper connection, so this becomes a challenge. It may or may not work to upgrade the current module.

For ordering modules with v1.16 firmware, I suggested ordering from Microchip Direct using the part number "RN52-I/RM116".


Best regards,
Josh

Re: RN52 firmware update (Ronnimbl)

$
0
0
Nope i used the SPP (serial port Profile) over bluetooth.
 I don't think you are supposed to FW upgrade it over SPP,
however it worked for me. I tested basically all functions, and a lot of it seems to work.

Re: RN52 firmware update (bmalbuck)

$
0
0
Thank you both @Ronnimbl and @mightymac
 
I was able to get my RN52-1/RM module FW updated to 1.16 following @mightymac suggestions and MChips original instructions for DFU over USB. If that failed was going to try @Ronnimbl SPP method.
 
Virtual Machine users take note...
 
Here was my issue: I run Mac OSX with all Windows variants configured in virtual machines using VMWare Fusion. Normally, default vmware configurations are sufficient but in this case of attaching RN52 over USB, the Windows instance (Win 8.1 where DFU Utility is installed), under USB & Bluetooth vmware settings, the default when a USB device is connected is "Ask what to do". Most devices will adhere and ask to connect to Mac (host) or Windows (VM). Well, changing this to "Connect to virtual machine" enforces USB devices that when physically connected always connect to VM if it is running. That did it! After changing the setting and rebooting VM, I was able to connect RN52 over USB as the Windows VM detected a new device.
 
@mightymac observations during and after the DFU process were true for me as well. It took 2 tries to get 1.16 flashed but in the end it worked. Also, @mightymac you should get a USB (mini or micro) breakout board with D- D+ VCC GND clearly labeled - instead of splicing. $2 on Sparkfun.
 
A few things I noticed upgrading to 1.16: Do to more flexible configurations offered in 1.16, the Extended Feature settings changed up a bit. I found by default the device was not discoverable at boot/start. My final settings (bits I needed on) was to issue, S%,00BF, followed by a reboot R,1. There were some other settings but I suggest looking these over to suit your project needs.
 
Thanks again for all the suggestions.

Re: RN52 firmware update (hanzibal)

$
0
0
Also had problems upgrading from fw v1.10 to v1.16 but eventually managed. In my case, Windows (XP in my case) did recognice the RN-52 module as a USB device but loaded the wrong driver - it tried to use some "Generic Bluetooth Radio" stuff which of course failed and resulted in a warning sign in the device manager.
 
Instead, I had to manually update the Windows driver to use the CSRBlueCoreUSB.inf driver that I happened to find in C:\Documents and Settings\<username>\Local Settings\Temp folder :-)
 
After loading the correct driver, the was enmerated as a USB DFU devuce and fw upgrade was a snap and v1.16 seem to work just fine. Hopefully, I2S works correctly now too.

Re: RN52 firmware update (slamike)

$
0
0
I know this is an old thread, however I just ran into a few issues with the process, and wanted to chime in. 
 
Hardware notes - My PWR_EN pin is NOT hard wired to 3V3. When I make this connection, the module consumes 1A of current, which is not something I want to happen permanently. I use tweezers to short the enable pin when I need to turn it on. It works like the momentary switch in the tutorial. I am quite certain that this configuration leads to an error prone and confusing firmware update process. 
 
I just upgraded from 1.10 to 1.16 using the following steps - 
  1. In order for the DFU utility to see the RN52 is ready for a firmware update, I had to connect GPIO3 to 3V3 to boot into that mode, both LEDs blink in sync. 
  2. Then, after selecting my target image to upload, the DFU utility would stop the progress about 15% in, complaining that it cannot change the device to DFU mode.
  3. While it is waiting for the device to enter DFU mode, I short PWR_EN to 3V3, and the DFU utility then progresses the firmware update. I had to do this twice in a single firmware update process before a successful update. 
Long story short - If your PWR_EN pin is not hardwired to 3V3, the DFU process will reboot your chip, and time out, unless you re-assert PWR_EN to be high. 

Re: RN52 firmware update (arbtec)

$
0
0
I
Following your informations it seems I'm able to upate to 1.16, but not sure because I can't go in CMD mode using hyperterminal : how to proceed when 1.16 update done?
I plug USB (CSR UART), press "power" button and drive low GPIO9 (hyperterminal ready at 115200)?
 
Thanks for your help...

Re: RN52 firmware update (DarioG)

$
0
0
These are only user forums. If you feel like, go submit a Support Ticket at their site.

Re: RN52 firmware update (MadMatt)

$
0
0
Yes, that's what I was thinking, instead of blinding hoping that some representative from microchip actually comes and posts here, that making a ticket might help.

Re: RN52 firmware update (pinkman)

$
0
0
Updated my RN52 to v1.16. I2S working only in 24bit sample width at 44.1kHz. Tried with S|,0112 as my I2S amplifier needs 32bits width with 44.1kHz, but it doesn't work. Tried with various combinations of sample width and sample rate, all output with default I2S 24bit sample width at 44.1kHz. I have raised a ticket, but not microchip have not responded yet.

Re: RN52 firmware update (MadMatt)

$
0
0
I'm waiting for a response from Mchip too re updating v 1.10 >1.16. We shall see how they respond.
Which I2S amplifier are you using?
 

Re: RN52 firmware update (pinkman)

$
0
0
I am using TDA7802, automotive audio amp. Unfortunately after a week, still no response from microchip yet. 
RN52 and my amp I2S configuration doesn't match, hopefully RN52 can make it work.

Re: RN52 firmware update (MadMatt)

$
0
0
Why do manufacturers only release partial datasheets. I was just wanting to confirm that the two devices were compatible to start with. It is unusual for an I2S input device (except a legacy device) to only accept data of a certain bit rate. I would have thought that any modern device should accept 16, 24 and 32 bit data.
One thing I would like to point out is that the RN52 will not output a masterclock. It is only the word clock (running at fs), bit clock, (running at 64x fs for 32 bit data) and the data line that the device can provide.
 
If your device needs a master clock to function then you will need to provide it from another source. The datasheet does indicate that the chip has an in built PLL but doesn't really say what it does. Some of TIs I2S input amplifiers have an integrated PLL that will support operation without the master clock.
 
I don't suppose this might be part of the problem?

Re: RN52 firmware update (pinkman)

$
0
0
The RN52 has master clock, it is from the I2S sclk (pin 26) that I realize the I2S is running at about 2.1168MHz. It has the clock waveform even when my amp is not attached. Most of the functions are working after the v1.16 update. except still can't change its configuration. 
 
My amp actually accept 25bits and 32 bits (depends on configuration). I believe 25bits and 24bits wouldn't differ much as it is left-justified (not too sure of this).
 
But my amp accepts 25bits with 48kHz, 92kHz or 192kHz, while RN52 can only runs 24bits with 44.1kHz, therefore it can't work.
 
I source for RN52 mainly because it has I2S output. Given that it is relatively higher cost than most unbranded bluetooth module, I think I will get a cheaper audio bluetooth with lineout and convert audio to I2S, or source for another audio bluetooth with I2S output, or get a design with pure analog audio. Sigh...

Re: RN52 firmware update (MadMatt)

$
0
0
You do realise that pin 26 is NOT a master clock output.
 
I2S is actually a three line data transmission protocol, not a 4 line as is used most of the time with today's devices.
 
As per 32 bit data, running at 44.1kHz.
 
Each stereo sample of data is sent down a 64 bit long word if you like. The bit clock, in this case, runs at 64x the sampling frequency (2 32 bit channels), so 2.8224MHz. Each rising edge of the bit clock is used to clock the 64 bit long data word into the audio sink device. The LR clock runs at fs and is used to tell the sink device what part of the 64 bit long data word is meant for the left channel and which is meant for the right. Half of the period of fs is equal to 32 sample periods of the bit clock, or represents the 32 bit data for one channel. The other half period of fs signals the 32 bits for the other channel.
 
With stereo 24 bit data running at 44.1kHz you're getting 2.1168MHz output on the SCK, which is representing the bit clock. Different nomenclature is often used for I2S inputs and outputs which can get a little confusing. Some use SCK to represent the System Clock, which is synonymous with the master clock. Some use SCK to represent the serial clock, which is used to represent the clock that is used to clock in the data present on the 'serial' data lines and is synonymous with the bit clock, so called the bit clock because it's used for clocking each individual bit into the sink device.
 
Then you've got even more confusion where there's the LRCLK, meaning, left/right clock, or the Word clock, which is used to represent the clock that switches to tell the sink device which part of the data stream is meant for the left or right channel.
 
The RN52 provides the standard 3 wire I2S communication required to transmit stereo audio. If your sink device requires a master clock to function then you will need to provide this separately!
 
Now the cut down data sheet brief that ST provide indicates that the device includes an on board PLL for the generation of a master clock. This will be required to run the noise shaping circuitry and over sampling of the amplifier.
 
According to the data sheet and as per the Flexiwatt pin out you need to connect the RN52s pin24 to pin12 and/or 13 of the power amplifier chip. Then you need to connect the RN52s pin25 to the power amps pin5 and the RN52s pin26 to the power amplifiers pin11.
 
It seems like the chip can work in either hardware or software control mode and I do not know which you are using, but this is important.
 
If you are using a hardware configuration then I'm guessing here that you need to set the configuration using pins 26 and 27 during device power on. You then need to enable the device and PLL via pin 2.
 
If you are using the power SO package then you will also need to use pins 20 and 21 to tell the device which serial input pin (pin 12 or 13) is going to be used as the data input. In addition to this you will also need to pull the device out of a mute condition by using pin 34.
 
If you are using the I2C bus to program the device then I do not know what you will need to do to make the thing work as the default configuration could be anything. It says that the PLL will function off of a 50 - 64x SCK, which would indicate that you do need to use 25 to 32 bit data. It is possible that this is only necessary in hardware mode, the PLL might be configurable via I2C to work from lower bit rates.
 
Two additional things, one related one not.
 
I have just done some tests of the I2S output myself, simply measuring the clock rates, to get an idea of what the settings do.
 
Setting the device to S|,0102 yields 44.1k sample rate with 24 bit data.
Setting the device to S|,0112 yields 44.1k sample rate with 24 bit data.
Setting the device to S|,0113 yields 44.1k sample rate with 24 bit data.
 
The last setting should work at 48, but does not. I wondered if this had anything do with the data being sent, so I loaded up a 48kHz sample rate file on my android device and nothing changed.
 
Setting the device to S|,0111 should give 32k sample rate and 32 bit data, but it's still stuck at 24 bit and 44.1k.
 
This is an improvement over the firmware before 1.16 that didn't work at all, but clearly the I2S settings don't work, the device is stuck in 24 bit 44.1kHz. I wonder if this has anything to do with the device sending the data to the RN52?
 
The second thing is that my trouble with the various S% settings seems to have come from the fact that I was using a Raspberry Pi's UART interface to program the RN52. Programming the same settings via the USB>UART bridge works as expected.
 
I have been in contact with a microchip representative, over the device with firmware version 1.10 failing to update to version 1.16 and we've yet to come to any kind of solution.

Re: RN52 firmware update (pinkman)

$
0
0
Hi, thanks for the detailed explanation. Sorry, what I meant is the bit clock at the pin 26 of RN52. The amp I'm using does have PLL enabled. I can control and read its data using the I2C communication, so I presume the PLL is working. By the way I am using software mode.
 
So, now I can see that you have the same issue as I have, the configuration of I2S is stuck at 24bit 44.1kHz. At least this shows firmware v1.16 has not working properly. I think this has nothing to do with your device sending data to RN52.
 
I am using PIC18, I checked every command signal when sending it and also verified with other commands is working, therefore I can be quite sure that either the S% command is not working or the device is not working well.

Re: RN52 firmware update (jbebel)

$
0
0
MadMatt, what was the outcome of working with a representative? Has anyone found a solution to updating 1.10 to 1.16? I've run into the same issue. I set up the circuit exactly as described, and the device isn't recognized by the computer. I was going to start debugging USB with USBPcap and wireshark, but I thought I'd see if anyone had resolved this yet, and if talking to a representative would help.

Re: RN52 firmware update (RISC)

Viewing all 49 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>