Currently we are working on a design for a secure beacon using the DA14580. We are trying to minimize the size of the PCB and additionally to make it harder to read the internal OTP.
Therefore we would like the PCB toNOThave UART TX RX or jtag pads. However this means we would need to program the device before assembly.
Our questions:
1) Is it possible to program the OTP before assembly using an adapter (likeadapter)
2) What are the minimal connections for programming only (VBAT,VPP,UART RX, URAT TX, JTAG, SWDIO, SW_CLOCK,RST)?
3) is it posible to program without xtal, antenna and VDCDC, VDCDC_RF circuit?
3) Is it possible to make the OTP unreadable or disable acces after programming?
Regards
Dieder Timmers
Device:
Hi diedertimmers,
Sorry for the delay, the team is working on it, we will get back when we have the answers to your questions.
Thanks MT_dialog
你好,我并不意味着劫持这个线程,但我cannot find a better place to post this question:
How can I use a the DA14580 dev kit to connect to MY hardware that has a DA14580 chip on?
Reason: I am done with development using the the DA dev kit. My app works as expected. I have put together my own PCB with a Da 14580 chip on it.
I would like to :
1. Use the DevKit FTDI/JLink to connect to my PCB/chip so that I can first test my design, then
2. Use the DevKit FTDI/JLink to program the OTP on my design so that it functions standalone.
这似乎我标准和logical development steps before going to production, yet I cannot find any reference as to how to do this.
What I would like is very simple: A list of the pin connections from the DA DevKit that I can connect to my PCB (example: SWDIO on DA14580Dev -> SWDIO on user Hardware).
Thanks for any help here, --klim
Hi Kim,
What devkit are you using. Using the Development Kit - Pro you can build a daughterboard that can do what you want al the info is available in the documentation section. For us that will be the next step before building a programmer based on the daughterboard specs.
Regards
Dieder Timmers
Hi klim9531,
You can find all the necessary schematics about the development kits (mother boards) in the Documents / Development kit Documentation section.
Thanks MT_dialog
Hello,
Thanks Dieder/MT_Dialog, these suggestions, while helpful, are a bit vague,-- maybe you could give us a quick list, or a hint at just which doc/page, something specific?...
For anyone else struggling with semi-answers, etc. here is what I did to get things *somewhat* working (more on that *somewhat* later). Note that I am using the Murata P2ML3078 motherboard, which has a socket to connect the Murata Type ZY daughterboard. The daughterboard has the DA14580 chip on it, but the chip is actually wrapped up in a module that contains the antenna (LBCA2HNZYZ-711). The advantage to this is that the module has already been through the somewhat daunting process of antenna certification, making for a shorter time to production.
Possibly my list below is obvious to other developers but, frankly, I have not found a description of what is happening between the Motherboard/Daughterboard/Jlink/Keil debugger. Magic. Therefore I have had to try to sort out what connections are needed to 'pretend' to the motherboard/JLink/Keil IDE, that my PCB is the daughterboard.
1. On my PCB, I pulled all the DA14580 pins out to pin headers (this is still a early development PCB).
2. In order to debug with the JLink debugger/Keil IDE, I need to connect 3 jumpers from my PCB to the motherboard: SWDIO to SDDIO, SWCLK to SWCLK, RST to RST.
3. In order to have power/ground on my PCB I need to connect 2 more jumpers from my PCB to the motherboard: VBAT to VCC_EXT(on the motherboard), GND to GND.
4. The Keil IDE still will not find my PCB, what gives? It seems that its because it needs the FTDI chip on the motherboard to act as flash memory, in order to 'feed the boot via UART'.
(I'm not even sure that this is correct-- remember when I said that none of this seems to be explained anywhere?)
5. So using the above assumption, I connect 4 more jumpers from my PCB to the motherboard: P0_5 to P0_5(UART1 RX), P0_4 to P0_4(UART1 TX), P0_2 to P0_2(CTS), P0_3 to P0_3(RTS).
Now I am able to connect to my PCB through the Murata Dev motherboard, download my app code, and start debug. I can see my amazing BLE device advertising, I can connect to it, set a notification, even send it some data. Life would be good for me, *except*-- I am still not able to get the data that I send over the BLE connection to output on the UART pin. The pin should be freed up from the flash programming at boot, and available to me for IO. A significant point is that when I disconnect my PCB and reconnect the motherboard/daughterboard combo, now my app works perfectly, data that I send over BLE is output to the UART pin. So it would *seem* that there is something in the BLE chip on my PCB, that is not the same as the BLE chip on the daughterboard. So for me, things are not quite figured out, but at least I can debug my app, on my PCB, and make some headway. For the reader that stumbles onto this post, hopefully this will help you to get your own PCB up and going.
In conclusion, Dieder/MT_Dialog, if you can confirm that the above is an accurate description of what people need, that would be great. And if you see something that I am missing in getting my PCB configured to perform correctly, possibly a flag that I need to set in the da14580_config.h file, or a calibration value that was previously burned into the OTP header in the chip on my PCB, can you please let me/us know?
Thanks, Klim
Hi,
The UART issue on your board may be caused by HW flow control. Make sure that the flow control (uart_flow_off()) is called in your code before you start writing to the UART.
Hi MHv_Dialog,
Thanks for the suggestion, I was able to find a way to work around the problem I described above, but I am not sure just why it works.
In the app code, I changed the UART Tx/Rx GPIO pin assignments from P0_4/P0_5 to P0_6/P0_7 and made some greenwire connections on my PCB.
I rebuilt and ran debug, and now the UART communications to my microcontroller occur without any hitches.
I have revisited my PCB layout and verified that there are NO other connections from the original Tx/Rx on the DA14580 to the Rx/Tx on my micro.
So there is no real possibility of any other components interfering, the original pins *should* be working just the same as the newly assigned pins, yet they are simply unresponsive.
Not sure why this is happening, I will post the solution when I figure it out.
Thanks again for your help and your reply, --klim