Welcome to the Intel Embedded Community.
We are working in your case and will be getting back to you soon.
In the meanwhile I have send you the Intel's eBMU datasheet for your reference.
There is another good document to review, it is the eBMU SSP-AT Application from Infineon; AT commands are described in detail here.
The UART interface is the main communication interface and it has four UART signals and two LPM control signals.
-UARTTXD and UARTRXD: are used for commands, responses and data.
-UARTRTS and UARTCTS: are used for hardware flow control. These signals are used together with two GPIOs to tell the other device (could be a host or a controller) when it may enter low power mode, when it should wake up and when it cannot transmit because the first device is in low power mode.
I recommend you to check if devices are in low power mode, this could be the reason of the communication failure.
The low power mode can be used when the device is in any of the following states:
- Page-/inquiry-scan mode.
- Connected with link in sniff.
These are some cases were the low power mode shall not be used:
- During connection set-up
- During device discovery.
- ACL link without sniff.
In order to allow the eBMU to enter low power mode, the host sets PIN P0.14 low, when eBMU is ready, it will also allow the host to enter LPM by setting P0.0 low. Before entering LPM, the host shall set UART CTS of eBMU high. Before entering LPM, eBMU will set its own UART RTS high. The host can wake up eBMU by setting UART CTS of eBMU low gain and stting P0.14 high again. eBMU can wake up the host by setting its own UART RTS low again and setting P0.0 high again.
Please review and let us know if this was the cause of the issue.
Thank you for your assistance.
I've been probing the board as best I can to look for bad power levels, and so far between a working setup and an unresponsive one I haven't found a difference.
I have to assume the P0.14 is being held high and therefore the device is not in Low power. The closest point I can get on the p0.14 line does show that the VDDUART ref voltage is there, but i suppose there is always the chance that the bga solder point under the bluetooth has a bad connection.
I was wondering, having looked at the documents it is capable of low power mode and still being discoverable, is it actually capable of receiving commands over UART whilst in LPM?
And under what conditions can it wake up to then initiate the host wakeup?
Again thanks for the help.
Spent some time trying to find ways of seeing if the BT chip was indeed in LPM as you suggest and decided to ground the p0.14 pin as close to the chip as i could.
The p0.14 is held high using VDDUART through a 10k resistor.
If i put an ammeter between the 10k and p0.14 I find that on a working device the pull down current is ~185 microAmps, but on an unresponsive one it is ~201 microAmps.
Having looked at the documentation i can see that the device can output typically 20 microAmps from p0.14.
So is there a chance that the p0.14 is set as an output (panasonic pan1321 docs state p0.14 as I/O but intel docs only show it as a reserved O).
If the pin cannot be an output is it then safe to come to the conclusion that because of the higher pull down current that the pin is not connected therefore not splitting the current?
Whilst I cannot yet take apart and prove this, it would be nice to have a possible diagnosis of the problem...
Effectively GPIO0.14 should be an output from the host controller and an input to the ePBM module
Are you using hardware flow control? If not you have to implement it since is mandatory.
Have you checked the level of the host’s UART RTS? if the level is high, the module will never respond to the host.
I have being checking the datasheet, and I have noticed some inconsistencies. If you check the block diagram on page 15 the host signals “WAKEUP_BT” is connected to P0.14 but if you check at the Reference Design on page 29 “WAKEUP_BT” is connected to P1.7 so that might be worth checking.
Our recommendation would be to contact with Panasonic line of Support since they might have more information regarding the programming of the PAN1321.
Also Panasonic Support might have access to the reference documentation on Section 12, which might be useful to troubleshooting your issue.
You can contact Panasonic Support in the following link: Panasonic Support
Hope this is useful to you.