Actions
Forum Thread Details
  • Replies 2 replies
  • Subscribers 50 subscribers
  • Views 83 views
  • Users 0 members are here
Related

Anyone else having PAN1326C2 initialisation problems after a power cycle?

Alistair

I noticed this issue before, and I thought I had worked around it, but my hack is not 100% reliable.

The problem is the PAN1326C2 does not always appear initialise correctly so does not respond. My solution to this was to detect when this happened by having a timeout on the initial response from the module, and pulling the reset line low if nothing came. The entire platform would reboot and almost all of the time it would spring in to life. Win.

The issue is that if I power cycle the entire system it almost never comes to life. If I press the reset button it is more likely to start, but not much more likely. The only way I have found to bring things to life is to press the reset button (or pull the reset line low) twice in quick succession. This is 100% reliable, but because I am resetting the MCU I can not implement this in code.

I even did a quick hack with a capacitor to act as a simple bit of nonvolatile memory and did reset twice in code, but even this did not work. Either the pulses are not long enough or by the time it gets to my code it is too late.

My original assumption for the need to reset at all was it is related 32768Hz oscillator output on P1.7 breaking the Bluetooth reset on P1.6. My gut reaction is this is still the issue, but there will be a chain of events and states leading to this.

Has anyone else experienced this? If so have you managed to work around it? 

I guess I could set up some kind of test setup to work out what timings work and what do not. A more simple approach may be to hack on another microcontroller to handle the reset, or even reprogram the MAX32625PICO to do it. My actual solution may be to simply show a warning light and require the use to double press the reset button.

  • it is all a bit of a blur to me, and I think I will definitely be building my final setup with BTStack, but for what it is worth, I may have hit a similar snag when trying to setup the PAN1326C2 for raw HCI, some random notes in https://github.com/saramic/sentinel-box/blob/main/WORK_LOG.md#the-cts-trap under  The CTS Trap. During boot, the PAN1326 holds its RTS output HIGH, which in turn feeds into P0.2 resulting in HCI command sitting in the transmit buffer and not going out. The fix at that time seemed to be to disable hardware CTS checking for the UART connected to the PAN1326. As I said, might be completely different to your setup but hope it helps ¯\_(ツ)_/¯

  • in reply to saramic

    Thanks for that. It gave me the clue that it was likely in the Arduino core, and although I don't know where exactly, the second reset needs to happen before the setup() routine is reached. The good news is I have a solution. The bad news is I have not 100% addressed the problem, but it is a reliable functional workaround.

    The solution appears to detect the failure (that I was doing before) and call the ARM function to do a processor reset ( NVIC_SystemReset(); ) without resetting the rest of the hardware. The list of possibilities for this working are long, and as much as I want to work out why this is the solution I don't have time before the deadline. As a result I am calling it job done and will add it to my list of puzzles for the future.