Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Bluetooth data reception delay

Status
Not open for further replies.

tiwari.sachin

Full Member level 6
Joined
Aug 1, 2009
Messages
341
Helped
3
Reputation
6
Reaction score
3
Trophy points
1,298
Location
India
Activity points
4,449
I am using RN4677 Bluetooth module from microchip and connecting that to mcu

I have checked only Bluetooth module by loading it on the PCB and changing internal buffer of module to 8kb and it works fine. I get continuous data.


When I connect the mcu, there is a delay in data reception. I am not sure why this is happening

My uart code if fine (have tested it without Bluetooth). I have a circular buffer in mcu that reads Bluetooth data.

During runtime, even though I send continuous data to Bluetooth, the circular buffer in mcu gets data with a delay.

There is no loss in data but it's more of a delay and the delay is random. What could be causing this issue??
 

Real time stack buffering to an IRQ response will affect latency. I Hope you aren't polling UART, if so is code like using DMA?

Latency is dependant on all buffers and stacks, with variability depending on depth and other task durations.
 

I understand that.

As said, we have two boards (same pcb design but different manufacturers)

On one board, it works fine but on the other, there are issues.


The board seems good and there are no shorts or anything like that.

I have over 2K boards on this new PCB and all have similar issue but the older one is working fine.
 

UART is interrupt based.

Its not coming to ISR (There is a delay)

When only bluetooth is checked. The data flow is perfect.
 

Two fab. vendors is new info. with one failing one passing.

Could there be a difference in loss tangent or lamination thickness and possible RF crosstalk or race conditions on logic or some other timing issue or ground effects.

Verify data, signal integrity at key locations. i.e. RSSI, CRC/ECC logic at speed or BT output.

Look at IRQ timing,,add break-points or test port out if necessary to indicate ACK/NAK or State Machine phase etc. for diagnostic probing.
 

I tried all possible thing but its all random. So have designed a new 4 layer design.

I have also posed the question on Bluetooth PCB design and hoping for some positive feedback
 

Update:

I tried removing the printer and tried to read Bluetooth data (without printing) and it worked fine. Tried reading about 200000 bytes with 2000 bytes every single time with a delay of a sec or two max and it worked well and at good speed.

When I connect printer and read the data and as well print, I am able to read the data for few KB (This is random) and then the data read/reception is delayed... Say for few seconds and then I get next byte... again prints properly for few hundred bytes and again hangs or say delay in data reception.

I would have activated strobes while I am printing and at the same time the bluetooth data is read in circular buffer (via UART receiver interrupt).

Is excess current drawn causing this issue. I see the voltage drop at the battery.

Some boards work perfectly fine but max dont.

I tried 4 strobes (Max current), 2 and even 1 strobe (low current) drive to check if it excess current drawn but couldnt get a clue.

Strobe current depends on what I am printing hence donot know exact current. Datasheet says if all dots of one strobe in ON it takes about 2.4 amps.

Could this be ESD?
Could this be current?
Is my regulator voltage (3.3V) varying... Seems stable when checked on CRO
Could that be some noise??

I am just not sure which way to go from here

- - - Updated - - -

Correction:

PCBs from old fab also have issue but the issue arises after some 50-70 prints while with new fab, it after 5-10 prints

Its not the MCU buffer that is the issue (debugged it and found that the bluetooth isnt receiving (I m not sure if its stored in bluetooth module buffer) data at all)
 

Update:

I tried removing the printer and tried to read Bluetooth data (without printing) and it worked fine. Tried reading about 200000 bytes with 2000 bytes every single time with a delay of a sec or two max and it worked well and at good speed.

When I connect printer and read the data and as well print, I am able to read the data for few KB (This is random) and then the data read/reception is delayed... Say for few seconds and then I get next byte... again prints properly for few hundred bytes and again hangs or say delay in data reception.

I would have activated strobes while I am printing and at the same time the bluetooth data is read in circular buffer (via UART receiver interrupt).

Is excess current drawn causing this issue. I see the voltage drop at the battery.

Some boards work perfectly fine but max dont.

I tried 4 strobes (Max current), 2 and even 1 strobe (low current) drive to check if it excess current drawn but couldnt get a clue.

Strobe current depends on what I am printing hence donot know exact current. Datasheet says if all dots of one strobe in ON it takes about 2.4 amps.

Could this be ESD?
Could this be current?
Is my regulator voltage (3.3V) varying... Seems stable when checked on CRO
Could that be some noise??

I am just not sure which way to go from here

- - - Updated - - -

Correction:

PCBs from old fab also have issue but the issue arises after some 50-70 prints while with new fab, it after 5-10 prints

Its not the MCU buffer that is the issue (debugged it and found that the bluetooth isnt receiving (I m not sure if its stored in bluetooth module buffer) data at all)

Looks like you need someone to debug for you. THere must be an obvious difference in dielectric, from copper layout, silk screen or solder mask, the latter being more a clue with the number of solder prints being the trigger and noise injection from printer cable... try CM choke or better battery source....


What test debug / fault isolation is built into design? any?
 

I donot have any fault isolation built.

The IO needed to drive printer are directly connected to MCU Pins



VDM is Battery Voltage (direct), Strobe, latch, data etc all connected to MCU directly
 

I tried supplying saparate 3.3V to bluetooth only and its working fine.

There sure is some variation that is happening which I am not able to track on CRO. I closely looked and I saw that when the print starts the 3.3V drops 200-300mV (Approx) for about 7ms and comes back to 3.3V and when the printing is about to stop, there are lot of small variations on 3.3V

How and what measures can i try to make this signal to be rock solid 3.3 always
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top