Hi team,
We're using a custom hardware which includes a DA14580 device. We want to boot it through another microcontroller as master (ADuCM4050) by using SPI protocol, so we have implemented some functions following the Application note document (booting from serial interfaces). The first packet sent is composed by the preamble, a 0x00 and the Length LS byte. If everything was fine, we may receive an ACK (its value is 0x02) in the position 3 of rx buffer (from 0), but that's not the case. In fact, we obtain the results shown in the attached pdf.
The problem here is that the SPI should send data, and then, receive the response from DA14580, but it seems that rx buffer catchs the [0xce, 0xc0, 0x02, 0xc0] secuence instead of [0xc0, 0xdc, 0xd4, 0x02]. The SPI bit rate set is the lowest.
Any idea about this?
Thanks.
Hi Alejandro,
Thanks for your question. Let me check it and I will get back to you.
Regards, PM_Dialog
Hi Alejandro,
Did you have setup wiring between the external microcontroller and the DA14580, or both are placed in the same PCB? In the first case, I would suggest to use shorter wires to reduce the noise. In the second case, please check in your PCB that you properly terminated the SPI lines. Typically we use 33 Ohm termination resistor. Regarding the sensitivity, due to spikes and reflections, in most of the cases, this was the reason that there wasn't any communication from the DA14580's side towards the master.
Thanks, PM_Dialog
Hi team,
Thanks for the reply. We have both components in the same PCB. We have put resistors in SPI lines following the recomendation, but it doesn't work properly yet. It's strange, because the DA14580 sends responses to the micro, so we think that the problem is related with timing (it seems like the micro makes a question and the dialog sends the answer before than ADuCM4050 finishes its question, so it can't take it to check if ACK or NACK).
Is possible that DA14580 is configured with a different bit rate, master/slave mode or any other and it ignores the SPI configuration of microcontroller? We don't see any other thing that could be generating this situation.
Thanks.
Hi Alejandro,
Let me check your question and I will let you know.
Thanks, PM_Dialog
Hi Alejandro,
It’s little bit strange… As mentioned before, this might be due to spikes, reflections and noise between the SPI signals. This is the in most common reason that there wasn't any communication from the DA14580's side towards the master. Regarding the bitrate, since the DA14580 is acting as a slave, the clock is generated by the other microcontroller which is acting as a master.
Thanks, PM_Dialog
Hi team,
Thanks for the reply. Finally, we decided to buy the DA14580 Dev-kit basic to work and discover what could be the problem. It seems that it is related with microcontroller configuration. When it tries to communicate with a chip to read or receive data, it sends "X" first and then receives "Y"; however, if it tries to write only, it receives responses by the way, so you can access to ACK in Rx buffer by deactivating the Read command in the SPI receiving function. And well... if we run the code, it receives the two first ACK, I mean, preamble and length+crc ACKs (not always), but not the 0xAA and 0x02 secuence in the end. We checked the Flash content and it was empty (full of 0xFF).
We followed the instructions of manuals and connected both devices as follows (SCLK, /CS, MISO and MOSI pins belong to microcontroller):
- SCLK to P0_0 of Dev-kit.
- /CS to P0_3 of Dev-kit.
- MISO to P0_6 of Dev-kit.
- MOSI to P0_5 of Dev-kit.
We already inserted a delay function (110 ms) and tried to connect with SPI pins of DA14580 Dev-kit (Flash), but it doesn't work. Is there any other point that we may to consider?
If we find a solution, we'll post it.
Thanks.
Hi team,
Finally, we really think that the problem is caused by wires connecting both devices, as you refered previously, because of spikes and reflections. Data received through MISO line is similar to data that we expect to receive, and sometimes appear reflected values as 0x70 and/or 0x50 hex data (they both are data used to init boot process).
The problem is we need to use these wires to connect devices among them. How can we avoid these effects? Is there any other factor that could be affecting? Maybe a jumper that we may to remove (or not) or any pin that must be connected in addition to four SPI lines?
Thank you very much.
Hi AlejandroCastillo,
In fact that you have a custom hardware and the lines are connected without fly wires, this is related to your PCB. Typically we use 33 Ohm termination resistor.
Thanks, PM_Dialog
Hi team,
We found the solution. The datasheet has a "non-desired effects" section where it explains possible bad responses related with the voltage regulator and ADC (one introduces noise effect to the other), so we tried to use shielded cable to check if we can reduce this and... it worked!
Thanks for your attention.
Hi AlejandroCastillo,
Glad that you figured you issue out and thanks for the indication. If you have any other issue, please create a new forum thread!
Thanks, PM_Dialog