Hello, I have configured a BlueNRG-M2SA as a network coprocessor using the provided DTM_SPI.hex file. I have connected it to an external uC and am able to read data from it. The problem is that as soon as the BlueNRG boots up and the interrupt is enabled on the uC for the IRQ pin, the BlueNRG repeatedly sends requests. The header it sends is always the same: { 0xFF, 0x90, 0x80, 0x60, 0x00 } and I'm assuming the data is too. I am not able to reach anywhere in my main application like initializing gatt or gap layers as it goes from handling one IRQ request to the next, back to back.
One potential problem that I am uncertain about is using the same pin, GPIO7, as both the Boot pin and IRQ pin. The BlueNRG is programmed to use the same pin for both of these. The external uC needs to drive this pin low on device reset, but then have it configured as an input by the time the BlueNRG firmware is ready. In order to avoid having two outputs connected to each other at one time, I configured the uC's pin as an input with an internal pulldown resistor, so that hopefully it would be enough to drive the boot pin low when the device is reset. Then I wouldn't have to worry about a potential short. Is this how it should be set up, or should I be configuring the uC pin as an output to make sure the BlueNRG launches the firmware instead of the bootloader? If so, how do you keep it from shorting?
I will try to probe this as soon as I have equipment available. But in the meantime if anyone has any ideas on what could be going wrong, that would be awesome!
Edit 1: After probing the IRQ and nCS pins, I found something strange near the end of the SPI transaction. At the end of a transaction, the IRQ line is cleared by the BlueNRG which must happen before the uC, or SPI master, can raise the nCS line thus ending the transaction. After the nCS line goes high, it only takes the BlueNRG about 70us to decide that it has more data to send and raises the IRQ line again. I am not really sure what could be going wrong here. The IRQ line is going high faster than my application can even do anything, which tells me these are false signals or the BlueNRG is unhappy for some reason. Please let me know if you have any ideas about what could be going wrong!
Edit 2: The data packet after the header that it keeps sending is as follows:
header: { 0xFF, 0x90, 0x80, 0x60, 0x00 }
data: { 0xFF20, 0x80C0, 0x8000 } + { 0x6060, ... } where the 0x6060 repeats for the remaining 90 bytes or so. The order of the bytes are: { 0x20, 0xFF, 0xC0, 0x80, ... } so lower byte first and then upper byte. I have been unable to match this with any sort of documented error or event.
Edit 3: Also, I am unsure what the BlueNRG_Activate_Select_Pin() function called inside BlueNRG_Stack_Initialization() is supposed to accomplish. In the BLE_SensorDemo_NWK example, it is activating a different CS pin than what is configured in SDK_EVAL_Spi_Init().
