Hi. I have a question.
If i use, in a custom board, a 16MHz Crystal that respect the specifications but is different from the 16MHz Crystal used in the basic dev board, when I use the DSPS or the HID mouse firmware, I have to change the trimming value or other xtal16m registers or something in software, or I can use firmwares without problems?
The firmware is storage in and loaded from, an external flash mem.
Thanks.
Device:
Hi drumste,
的调整值XTAL16是由software in the reference designs and in the software examples. The value that is provided is an average value that dialog tested on the expert dev kits. That doesn't mean that this value will work with all crystal oscillators. If you would like to use the examples on other reference designs you would have to trim your crystal in order to be sure.
Thanks MT_dialog
Ok. I found the production test tool for trimming the crystal. I try it on the dev basic board for practise, but when I use the xtrim caltest, the output is status=26. I use a 1Hz square wave (duty cycle 50%) on the P1_1 of amplitude 3.3V.
What it mean?
I did the same test with my custom board but the problem is that the prodtest tool can't communicate with the prod_test.hex inside the module (status=9). In my custom board I use a 16MHz crystal with 50ppm of tolerance, 18pF of Load cap. and freq. stability of 30ppm. The type of crystal can be the problem?
For prod_test.hex execution, it is used the external crystal or the internal RC oscillator?
Hi drumste
You can find all the errors of the production test tool in the document UM-B-008 : Production test tool in table 2 : return codes. Concerning the crystal the XTAL16 is used and not the internal RC oscillator. Also please have a look at the datasheet to check the recommended operating conditions for the 16 MHz oscillator. The crystal should meet those requirements i dont think that the type of the crystal should make the difference since the recommended operating conditions are met.
Thanks MT_dialog
It's possible there is some kind of BLE module damage?
I analyzed the spectrum outside the antenna with the DSPS profile, and it seems that the band spreads outside the Bluetooth limit.
I also try to insert a uart_write() inside the main loop of a DSPS and compare the experiment with the dev basic board: With the custom board the characters come outside the uart correctly but I can't find it with the android app. With the dev board, the characters don't come outside but I can find it with the android app.
I did other experiments and in everyone the custom board and the dev board had different behavior.
I thought that the problem can be the trimming of crystal but I can't use the prod_test app with my custom board.
我也试图改变晶体的相同one but the behaviors are the same.
It's possible that another malfunction reason could be a too high reflected power from antenna?
Otherwise, there is some register that is important to set when the BLE is use in a custom board?
The fact that my module is a DA14580-01 1NCAC instead 1NCAD could mean something?
Hi drumste,
There is no register that should be specifically be set when using a custom board, About the crystal you are using seems that the Load capacitance is high (18pF), also the frequency stability is quite high (30ppm), so the RF frequency could be off too much at extreme temperatures especially knowing that the XTAL could face non-optimal trimming, having an initial error of 10ppm (since the trimming capabily is guaranteed to trim +-40ppm Xtals and yours is +/-50ppm and possibly could not be optimally trimmed). So the large CL plus the possibly large negative tolerance could result in a large frequency offset. Also you have to consider the ESR of this XTAL and should not exceed 100Ohm. The conclusion is that the 580 should operate (if not in extreme temperatures) but the frequency could face a large offset in some case. Also since you dont get any advertising, the antenna sound like a good reason.
Thanks MT_dialog
Hi.
I resolved the main problem: I had soldered a wrong component in the buck inductance position of my custom board. Resolved it, now there is another problem: the dialog HID mouse profile run correctly (advertising, pairing and report) but the DSPS profile doesn't work. It doesn't work means that, if I load the device version of the DSPS profile, I can't find the device with the android DSPS app.
which may be the reason of this behavior ?
I remind you that I use a 16M crystal (the MA-506) with a freq. tolerance of 50ppm, freq. stability of 30ppm, 18pF of load capacitance and 40ohm ESR)
I also tryed to do the 16M crystal calibration with the prod_test tool, but the output status is 26 that is a "calibration out of range" error , but I don't understand exactly what it means and why it outputs this error. Probably the accuracy of the pulse? (I generated the pulse with an AGILENT 33120A arbitrary waveform generator, with a 1Hz square wave, 50% of duty cycle)
Hi,
1. For trimming problem, could you use the waveform with the following settings?
High: 500.000 msec +/- 10 ppm (0.005 msec)(<= 3.3 V)
Low: 10 msec +/- 1 msec (0V).
2. For DSPS problem, could you check if the firmware runs up correctly on your board? And how did you run it? Load it to RAM via JTAG or flash it to memory?
Actually, for the test, I load the firmware through UART at 57.6 Kbit/s (pins P0_4 and P0_5). I don't use the jtag because I can't load the firmware through it.
At the end of the tests, in the normally use of the board, the firmware will be load by the external flash.
How can I check if the DSPS work properly?
I tried to run the DSPS device firmware on the Basic_dev_board and on my custom board: with the basic_dev_board, the firmware rum properly and I can find it with the android app, on the contrary, with my board, I can't find it.
It is strange if we consider that the HID firmware work properly with both boards. It's possible there is difference in radio output power settings from HID and DSPS firmware? otherwise, it's possible that there is something in hardware that prevent the correct execution of DSPS? some settings? if not, you have idea about what can be the problem?
Hi,
Things you could do are
check your download process is correct.
Enable UART console print via UART2 to print messages out. Search for the keyword CFG_PRINTF in code base.