I’ve been working on an SL6087 chip communicating with a bluetooth module over UART2 using FCM at 115200 and everything seemed fine.
Since finishing the code I needed and then loading it onto some of a new batch of my custom pcb a significant portion of the boards don’t seem to register any communication out from the Bluetooth on the uart.
With working boards the bluetooth successfully passes back data in packets to the SL and I have it printed out through TRACE. On the suspect boards nothing is ever printed out.
Opening UART2, subscribing to the FCM on that channel is fine, and it is happy to then change over to data, the bluetooth device does listen to the FCM as i can change the name in the code and it does change in the real world on all the boards. But without the data being passed back through the FCM to the SL pairing devices to the bluetooth can’t happen, and all subsequent commands don’t work.
To try finding out what is wrong i changed the baud rate the FCM was set to and that stopped communication on working boards. So with that I ran through all the baud rates the bluetooth chip can be set to but none worked.
The only thing I can think of is that the baud rate tolerance is exceeded between SL6087 and Bluetooth chip. Are there any other things I should be thinking of?
For notes, of about 10 identical boards 4 seem to exhibit the exact same lack of data from bluetooth, but all seem to be atleast set to be discoverable and named at startup of the openAT application.
Thanks in advance for any help, I don’t want to have a pile of wasted materials building on my desk
Thanks for getting back to me, its embarrassing to say but I wish.
I’ve been brought into a small company to finish a project that they had thrown back at them from a a company they sub contracted to.
So needless to say the equipment and tools are archaic to non existent.
The other company cut a lot of corners and really tried to hash out a very ungraceful solution, so i’m always biased towards thinking its something they screwed up.
But this time I suppose the answer is get a scope and stick it on the output from the bluetooth to see if it even tries talking?
I’ve had a look and persuaded the company to sort out a modest Pico 25MHz for testing.
I’m assuming that 25MHz at 200M samples/s is fine for very light work like this, plus can have it tomorrow and hopefully find out if i have to then ask them to get some hot air rework equipment for the modules if they are faulty, its fun in the world of diagnostics…
Would have liked something a bit better for more intensive applications later, but i’ll take what I can get for now!?
Thanks for the assistance, reassurance that i’m not being stupid is always welcomed
-Chris
Hi again, found some time between other problems to look at the bluetooth again.
No traffic coming from the bluetooth Tx, bluetooth Rx is receiving the commands correctly.
Pulse width is 8.5 micro seconds so does conform to 115200bps or baud.
Am I correct in thinking that 3v on the data line indicates that it is being driven by whoever has the output for that line?
Because i’m getting identical 3v noise on both data lines.
I feel like the system is missing some sort of initialisation…
I’ll investigate that, looking at rudimentary drawings it appears Bluetooth Tx on p0.4 (labelled as Uart Transmit data on the module documentation) is connected to RxD2 on the Sl chip, and vice versa for p0.5 Bluetooth Rx to Sl TxD2.
Am I silly for assuming that brand new chips would have a set initialization from the factory, because if that is a constant and the code loaded is the same, why would some possibly have Tx/Rx swapped? So far about 10% of new unused boards seem to have Bluetooth perfectly.
I have noticed the 3V power going to the board has the same ripple I saw on the data lines (like the capacitors aren’t big enough to flatten a sine wave). This does mean it can go lower than it really should, would this be a huge problem. (ie Bluetooth rated 2.9-4.2V, i see around 2.5-3.5V.)
My concern is if the power was too low for some boards, why would they still get through naming and discoverable settings from the Sl chip.
I can’t wait to get a chance to begin version 2…
Thanks for your patience.
-Chris
To correct the last post.
Turns out the previous lot did indeed do Rx > Tx and Tx > Rx, which was wrong after finding the diagrams and correlating to pin-out sheets for the Bluetooth and the sl chip.
But the newer ones which also have the problem have updated PCB with swap-over so Bluetooth Tx Out > Sl Tx In, and Sl Rx Out > Bluetooth Rx In.
So you were indeed correct, but sadly that problem had been found (albeit not until actually making a prototype board… ).
So I’m back to wondering if the Bluetooth has some sort of initialization for verbosity as mad as that sounds?!
The obvious thing to do is swap a “working” for “non-working” module. This will rule out the factory initialization.
If I understand your description correctly, you have a proof that the BT module does hear the SL talking?
Anyway, I’d say it’s either the power; try to get the voltage above 2.9 by swapping higher capacitors, tuning the power source etc.
Even more probable is a problem on the PCB, where the BT->SL line is hard-wired to 3V. You can check it while power is off. Also while powered on, test how “strong” the 3V are by adding a 1k resistor to GND.
In our company, 90% of problems are bad soldering (thank EU for lead-less solder )
But are you sure that the chips are brand new, and haven’t been through any programming process before assembly…?
Are all the modules at the same revision?
Good point - if it was a wiring fault, then none should work.
Inadequate power supply is a very, very frequent cause of problems with cellular devices, because they take very, very large current spikes - on the order of several amps.
This is, in fact, a common issue with all kinds of radio transmitter - so also having Bluetooth in there would just compound any issues!
This is where a decent scope really does help to see spikes & droops on the power supplies.
I’ve gone to management and suggest they let me take apart a known bad and good one, we’ll see if that goes anywhere anytime soon.
The earlier ones were software version 7, newer ones are software version 8.
There is a growing collection of new ones running 8 that are fine.
I suppose in my cynical mind i can’t be sure of anything, i’ve been told brand new panasonic soldered to board and then left to sit for a year or 2 whilst a few were made up for testing, certification, proof of system readiness etc etc.
But even if they had other initialisation, from what i can gather in the pan1321 documentation, if VDDUART is supplied with power then the UART interface is always live(?). And added to that the only other thing that would stop responses would be if it were in stream mode, which requires a connection to a remote bt device, and will cancel itself after 20 seconds if connection goes silent.
I used roundabout logic: the oscilloscope showed some clean signals from the SL, and the BT chip will change its name if I change the name set by the SL in the code. Although i’ll admit, i’m paranoid that when the device doesn’t seem to want to work properly, the naming takes a lot longer to actually get picked up by any remote device. Could that be because the signal from the bt itself is also affected by bad power (if that is the assumed case)?
By my logic using a 1k to GND means i want to have an ammeter in between and see if it sustains 3mA without dropping out?
I’ll have to get a shot of the UART and power lines on here, then you can confirm if it should have worried (inexperienced) me as much as it did.
Thanks for all the help. It would definitely be a lot simpler if there were some boards free for me to desolder.
Another consequence of not having many of the tools needed for the hardware side.
It’s enough to just measure the voltage (precisely) after the resistor is added. It will tell you if it’s
hard 3V: probably the line touches the 3V line somewhere
strong 3V (say it drops to 2.98V): the BT module keeps the line high because it has nothing to say
weak 3V (drops to <0.5 V): it’s a leak from SL input, and the BT module is not connected to this line at all (bad soldering).
But if you say that sometimes things take longer than usual, then the power supply seems to be the most probable cause of your trouble.
Can you check the voltage levels on working vs. broken boards? Preferably with oscilloscope. Inspect the depth and duration of voltage drops. It could be just a bad capacitor… or an electrolytic capacitor placed the other way… or anything.
Between getting stuck at an airport overnight and suddenly becoming IT support (“have you tried turning it off and back on again…”), I’ve got back to wrangling Bluetooth.
I made up a DC power supply and hijacked all incoming pins from the unreliable source used for final product.
The power is now a lot more stable. However that did not fix any problems.
Grounding through a 1k ohm resistor brought the 1.9V UARTS down to 1.5V on the BT driven line, and 1.3V on the SL driven line.
The 3v power going into the BT module dropped from 2.92V to 2.9V, sometimes 2.89V, but having tested a working device on the same power supply that wasn’t really a problem for it.
Since the data lines are both driven by respective modules, and power stability is now not an issue I’m really unsure about what is wrong. Having probed the UARTCTS signal into the Bluetooth (its statically tied to the VDDUART on the board so not controlled really…), it is the correct 1.9V so unless the solder on the BGA for that pin is bad it is technically held awake.
Anyone have experience with the Pan 1321? Does it still process commands from host in low power state?
I have thrown a question intels’ way since they market the PMB chip that the BT uses, hopefully this bad dream will be over soon.
More a status update than anything I think this time, but any ideas are welcomed as usual.
Quick question, the BT has an LPM wake-up pin (p0.14) that is supposed to be high for the device to be in full power mode.
The PCB in-front of me has VDDUART power line through a 10k ohm resistor to this pin to keep it high.
I tapped off after the resistor through an ammeter to a 1k resistor to ground and found that, of the 2 good ones and 2 bad ones i tested, both goods had a sinking current of approx 185 micro-amp, whereas both bad ones seemed to have approx 201 micro-amp. Its a tiny difference but is there a chance that this could mean there is no connection to the pin on bad ones therefore no division of the current so it all goes to ground?
Incidentally VDDUART is 1.8-1.9V so quite how 1.9/11k = 201 micro-amps I don’t know…
I’ve persuaded management to hand over one of their dud pcb’s, no idea if the BT chip itself works, but going to de-solder and find out in coming days.
I have learned an important lesson, even the schematics can be entirely wrong.
Whoever sat down and designed this system wanted to make my task of finalizing it a living hell.
Turns out that the RTS and CTS pins for the BT module and the SL module were mislabeled and connected Input to input and output to output. (which was not what the designs said)
That wouldn’t have been a problem if the previous lot had not then pulled up the input pins to Vcc with a tiny 10k resistor.
Then they cut the BT input from the pulled up SL input and left it floating in the breeze.
So whilst the CTS input into the BT looked low, setting the scope to trigger on a falling edge i found a tiny discharge each time the CTS was probed. Tracing ghost signals through pins that are hanging and have no documentation with an LGA module is ridiculous.
Thanks for all your help regardless, I learned quite a lot into what turned out to be analogue circuitry…
Although having found the problem I feel like a right muppet
)