BlueSaab 6.1 - No "BlueSaab" Bluetooth device available after power up

[czabel]

OK, I just beeped out every pin pair on the STM32, nothing shows a bridge.
I get slight hiccups on the Vcc/Gnd pairs, but that should just be decoupling caps charging up. Expected behavior.

I got a scope on the Osc, and found some interesting behavior. Screenshots incoming:

Zoomed out view: You can see there is a periodic hiccup, happening with a frequency of 1kHz.


Zooming in: there's a lot going on in this hiccup, including square waves.



Most of the time, it's a good 8MHz waveform:


Having said all that... This only shows up when I connect power to the "EXT VCC" pins. I get NO WAVEFORM on the Osc when I connect my FTDI cable to the FTDI header, it's tied high at 2V.

VDD/VSS are reading what I would expect: power and ground.

On the RN52 side of things, I'm reading the following:
Pins 3, 5, 11, 21 (STATUS, RESET, CMD, PWREN) are all low.
Pin 16 (UART_TX) is high, at 3V.
Pin 17 (UART_RX) is low.

So, given that I only see the oscillator working when the STM32 has 5V, and not even consistently... I'm just going to buy a few more of both the oscillator and the chip, and try again. Not the most fun thing... Getting the STM32 off the board might be a bit of a pain, but unless you have any insights here Karlis, I'm stumped.

[Seth]

So you’re applying 3.3v to the EXT VCC pin, and you get that ripple? I was going to suggest looking at the vreg to make sure it’s putting out 3.3v...

It could be the oscillator or a bad connection to it; much easier to try that than the stm32...

Also, it’s hard to read the oscillator with a scope without “breaking” the oscillation due to extra impedance that the oscope leads introduce...but that’s just what I’ve been told, I’m not a EE. But at least you did see it sometimes.

Thanks for not bashing us and working with us to get it sorted out. 

Seth

On Mon, Sep 23, 2019 at 13:38 czabel [via BlueSaab Forum] <[hidden email]> wrote:

OK, I just beeped out every pin pair on the STM32, nothing shows a bridge.
I get slight hiccups on the Vcc/Gnd pairs, but that should just be decoupling caps charging up. Expected behavior.

I got a scope on the Osc, and found some interesting behavior. Screenshots incoming:

Zoomed out view: You can see there is a periodic hiccup, happening with a frequency of 1kHz.


Zooming in: there's a lot going on in this hiccup, including square waves.



Most of the time, it's a good 8MHz waveform:


Having said all that... This only shows up when I connect power to the "EXT VCC" pins. I get NO WAVEFORM on the Osc when I connect my FTDI cable to the FTDI header, it's tied high at 2V.

VDD/VSS are reading what I would expect: power and ground.

On the RN52 side of things, I'm reading the following:
Pins 3, 5, 11, 21 (STATUS, RESET, CMD, PWREN) are all low.
Pin 16 (UART_TX) is high, at 3V.
Pin 17 (UART_RX) is low.

So, given that I only see the oscillator working when the STM32 has 5V, and not even consistently... I'm just going to buy a few more of both the oscillator and the chip, and try again. Not the most fun thing... Getting the STM32 off the board might be a bit of a pain, but unless you have any insights here Karlis, I'm stumped.

---

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

http://bluesaab-forum.2349123.n4.nabble.com/BlueSaab-6-1-No-BlueSaab-Bluetooth-device-available-after-power-up-tp1492p1527.html

To start a new topic under Firmware, email [hidden email]
To unsubscribe from Firmware, click here.
NAML

[czabel]

Yeah, of course - and hey, the more things I find, the better my How To document will be later!

To be clear, I first applied the 5V from the FTDI cable to the EXT VCC pin, because I wasn't paying attention. I then switched to the FTDI header's VCC connection and verified that the LDO is operating as expected, but nothing showed up on the oscillator. Perhaps that's due to just being on the edge of operation, and the scope lead broke things. You're right about that having an effect, but even if it was loading the circuit enough it wouldn't be periodic like that, nothing on the scope should be running at 1kHz...

Alright, swapped probes to a higher impedance option, and got this:


It may not be pretty, but I feel fairly confident the oscillator is working as intended.

At this point I'm leaning strongly toward the "I cooked my STM32" option, but I still don't understand how that would still allow the programming to occur, but not regular operation. Bizarre.

Seth, you're right - the oscillator will be the first thing to swap out - but I'll buy both to avoid waiting for another shipment, and I'm getting multiples this time... :)

[Seth]

So it just clicked with me this morning rereading your post; if you applied 5v to EXT pin, that means you hit the stm32 with 5v, but it’s not 5v tolerant.....I would suspect ic damage at this point...and probably with the RN52 as well.......

You might wanna but replacements for both chips unfortunately :-/

On Mon, Sep 23, 2019 at 19:11 czabel [via BlueSaab Forum] <[hidden email]> wrote:

Yeah, of course - and hey, the more things I find, the better my How To document will be later!

To be clear, I first applied the 5V from the FTDI cable to the EXT VCC pin, because I wasn't paying attention. I then switched to the FTDI header's VCC connection and verified that the LDO is operating as expected, but nothing showed up on the oscillator. Perhaps that's due to just being on the edge of operation, and the scope lead broke things. You're right about that having an effect, but even if it was loading the circuit enough it wouldn't be periodic like that, nothing on the scope should be running at 1kHz...

Alright, swapped probes to a higher impedance option, and got this:


It may not be pretty, but I feel fairly confident the oscillator is working as intended.

At this point I'm leaning strongly toward the "I cooked my STM32" option, but I still don't understand how that would still allow the programming to occur, but not regular operation. Bizarre.

Seth, you're right - the oscillator will be the first thing to swap out - but I'll buy both to avoid waiting for another shipment, and I'm getting multiples this time... :)

---

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

http://bluesaab-forum.2349123.n4.nabble.com/BlueSaab-6-1-No-BlueSaab-Bluetooth-device-available-after-power-up-tp1492p1529.html

To start a new topic under Firmware, email [hidden email]
To unsubscribe from Firmware, click here.
NAML

[czabel]

Ah yes, would you look at that... Maximum voltage is 4V.

The RN52 doesn't list an absolute maximum, is there a way I can check operation of that module after I remove the STM32? (I will probably just be buying another set of everything at this point, to start fresh...)

[Karlis]

If you apply 3.3V and GND, then tie 3.3V to PWREN pin on RN52 it should boot up. If it doesn't -> bad news...

[czabel]

Karlis wrote

If you apply 3.3V and GND, then tie 3.3V to PWREN pin on RN52 it should boot up. If it doesn't -> bad news...

Thanks Karlis. Should I be looking for the LEDs to start flashing, and a Bluetooth device to show up on my phone in pairing mode? I ask because I don't know what sort of firmware comes on this guy from the factory.

[Karlis]

If everything is fine, you should see blue and red LEDs flash simultaneously for ~3 seconds and then switch over to a mode where blue and red LEDs flash alternatively indicating that RN52 is in "Discoverable/Connectable" (Pairing) mode. If that's the case, RN52 is alive and what you should see in your phone's Bluetooth settings is a device named "RN52-XXXX" where "XXXX" is the last four characters of particular RN52 modules BD_ADDR (MAC address).

[czabel]

Karlis wrote

If everything is fine, you should see blue and red LEDs flash simultaneously for ~3 seconds and then switch over to a mode where blue and red LEDs flash alternatively indicating that RN52 is in "Discoverable/Connectable" (Pairing) mode. If that's the case, RN52 is alive and what you should see in your phone's Bluetooth settings is a device named "RN52-XXXX" where "XXXX" is the last four characters of particular RN52 modules BD_ADDR (MAC address).

Thanks Karlis.

She's dead as well. Time to start fresh! I'll update you guys when I get all my new parts in and assembled... And I'll be much more methodical this time. Power track first, check the RN52 off the board, etc. And now I've got more SMD soldering practice, so I should do better this next time. I'll work on the How To document in the meantime.

Thanks for your help guys.

[Seth]

Yeah, that’s actually the first thing I do when building a module, is put the vreg and parts on and test to make sure I have 3.3v, so I don’t fry my expensive parts by accident. 

But that process doesn’t help if you later apply the wrong voltage to the EXT pins lol

I prob should have made the silkscreen say “3.3v” instead of “VCC”.....

On Tue, Sep 24, 2019 at 12:53 czabel [via BlueSaab Forum] <[hidden email]> wrote:

Karlis wrote

If everything is fine, you should see blue and red LEDs flash simultaneously for ~3 seconds and then switch over to a mode where blue and red LEDs flash alternatively indicating that RN52 is in "Discoverable/Connectable" (Pairing) mode. If that's the case, RN52 is alive and what you should see in your phone's Bluetooth settings is a device named "RN52-XXXX" where "XXXX" is the last four characters of particular RN52 modules BD_ADDR (MAC address).

Thanks Karlis.

She's dead as well. Time to start fresh! I'll update you guys when I get all my new parts in and assembled... And I'll be much more methodical this time. Power track first, check the RN52 off the board, etc. And now I've got more SMD soldering practice, so I should do better this next time. I'll work on the How To document in the meantime.

Thanks for your help guys.

---

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

http://bluesaab-forum.2349123.n4.nabble.com/BlueSaab-6-1-No-BlueSaab-Bluetooth-device-available-after-power-up-tp1492p1535.html

To start a new topic under Firmware, email [hidden email]
To unsubscribe from Firmware, click here.
NAML

[czabel]

Seth wrote

Yeah, that’s actually the first thing I do when building a module, is put
the vreg and parts on and test to make sure I have 3.3v, so I don’t fry my
expensive parts by accident.

But that process doesn’t help if you later apply the wrong voltage to the
EXT pins lol

I prob should have made the silkscreen say “3.3v” instead of “VCC”.....

It's all good, I'm just a little embarrassed - I know better than to do what I did (I am an EE, after all), I was just excited and rushed through it.

Ah well, not the end of the world. Just need to place another DigiKey order.

[czabel]

Alright, it's alive!

Got the power components and the RN52 populated, and I get pairing LEDs and can see it on my phone. Sweet!

Is there anything I can do along these lines as I populate more things onto the board? Can I test the CAN IC in some way, or anything else?

[Seth]

I’m not too familiar with the stm32, so I say just solder it and pray ;)

On Tue, Oct 1, 2019 at 22:50 czabel [via BlueSaab Forum] <[hidden email]> wrote:

Alright, it's alive!

Got the power components and the RN52 populated, and I get pairing LEDs and can see it on my phone. Sweet!

Is there anything I can do along these lines as I populate more things onto the board? Can I test the CAN IC in some way, or anything else?

2000 9-5 Aero 5-Speed

---

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

http://bluesaab-forum.2349123.n4.nabble.com/BlueSaab-6-1-No-BlueSaab-Bluetooth-device-available-after-power-up-tp1492p1538.html

To start a new topic under Firmware, email [hidden email]
To unsubscribe from Firmware, click here.
NAML

[czabel]

@Seth,

Sounds like a plan! I populated the amplifier and CAN IC circuits last night, and the RN52 still fires right up, so we're on track still. I'm probably going to put all the STM32 passive components in place first, then stick the chip in and see what happens... I'll update you guys when I get there.

As far as work on the microphone input goes, @karlis what is the workflow like for getting modified code onto the board? Basically, what IDE would you suggest, and do I simply compile and use the same flasher tool?

I am also curious if there is a way to debug in-system at all. I imagine if that's possible, it won't be by using the FTDI cable.

[Karlis]

So one more thing you can check (and this is CAN specific) - if LED pulses in green every second or so. That's an indication, that STM32 is packing and putting a CAN frame on the bus. Now, wether the frame actually makes to the bus through the transceiver is another question, but this should give you a good indication as to what STM32 is doing.

As for code - I'm using Eclipse with ARM GCC package. Even without that, if you connect to UART2 and issue "H" (no quotes), you'll see a few debug commands (including invoking of voice assistant) that should exercise RN52 mic-in.

[czabel]

@Karlis,

Thanks for the tip. That debug message is interesting - is there a spec somewhere for commands I can try to send? I know the RN52 has some sort of basic command interface, is that done through the STM32 in this configuration, or is there another way to do that?

I'm going to try and get set up with an IDE so I can contribute - it's one thing to get the mic working, but to get it set correctly in regular operation is what my ultimate goal is.

[Karlis]

"H" will show you list of debug commands you can use. RN52 ASCII API is not exposed to outside world. Instead of that there's a wrapper around it that only exposes a subset of debug commands that can be used.

[czabel]

Woo! She's programmed! I don't know if I have ever been so happy to see a green light. Thank you both for your help troubleshooting this. Now, to start messing around with HFP!

[Karlis]

Congrats ! Hopefully it works on the real car as well . Mind you, in order to get HFP capabilities, you'll have to change a couple of things in the code and re-flash BlueSaab. If I recall it correctly, RN52 is configured only to disclose A2DP capabilities for now. There's a pair of settings (SD and SK) in RN52strings.h that both need to be changed from 04 to 0C. That should enable both A2DP and HFP during discovery. Good luck!

[czabel]

It works GREAT in the car! Super happy about this, thanks for your help so far!

I have a few more questions, which maybe should go in a new topic at this point...
Would you be willing to help me setting up Eclipse to spit out new binary files? I've installed the ARM GCC plugin, and have imported the BlueSaab project as "C++ Makefile Project from Existing Code," but I cannot for the life of me figure out how to make it build using the existing makefile.

It's probably a mix of broken things - if you have any tips on what I might be doing wrong, I'd love to hear them.

I've also added an S| command, to set it to 32-bit 48k audio. I want to enable the aptX codec, but from what I've read, you have to pay Qualcom for the rights to that - is that correct?