The reset button doesn't work when using Smart Snippets

9 posts / 0 new
Last post
JJW
Offline
Last seen:6 years 10 months ago
加入:2014-06-18 15:28
The reset button doesn't work when using Smart Snippets

Hi,

I have a hex file. And I downloaded the latest version of the Smart Snippets. When I use the UART boot to download the hex file, the Reset button does not work. I try to hold the button, it does not work, either.

It only said that "Timeout: Reset signal not detected for more than 15000 msecs."
Why? Can someone help me?

JE_Dialog
Offline
Last seen:12 hours 55 min ago
Staff
加入:2013-12-05 14:02
Hello JJW, Which development

Hello JJW, Which development board are you using : is it the motherboard/daugtherboard or the new BASIC development all in one kit ?

BR JE_Dialog

tapio
Offline
Last seen:2 years 1 month ago
加入:2014-03-24 22:49
Hello,

Hello,

I am having a similar problem, using SmartSnippets to download .hex file to the SPI Flash, on the Basic board.
The following is stated in the html Help chapter, but I am not clear what the meaning is for "Special firmware is downloaded".
I get the similar Timeout message.

----------From User Guide "SPI Flash Programmer":

The user can select a .hex or binary image file in order to burn it to the SPI Flash Memory. The following actions are available:

Connect: Special firmware is downloaded to the chip to allow the user interact with the SPI Flash memory. This is a mandatory step before enabling the other actions. Please note that this firmware is different from the firmware downloaded when pressing the ‘Connect’ button on the OTP Image tab. If a ‘CRC does not match’ shows up, please press the ‘Connect’ button again and then the hardware reset button on the board to restart the download process.

Tap.

klim9531
Offline
Last seen:4 years 6 months ago
加入:2015-01-28 23:52
Hi JE_Dialog/JJW,

Hi JE_Dialog/JJW,

I am trying to burn the OTP on my custom PCB so that I can test it as a standalone device.

I am getting the same error "Timeout: Reset signal not detected for more than 16000 msecs" when I try to burn the OTP from Smartsnippets (the complete log is down below).

I am using the Murata P2ML3078 Motherboard (with my custom PCB).

My custom PCB is jumpered to the pin headers on the motherboard, and I believe that I have all the needed connections present, based upon the fact that I can connect from the Keil IDE and download/run my firmware in Debug mode.

On my PCB I am using P0-0 and P0_1 to connect to the FTDI chip, I make those the selections in SmartSnippets, along with P0_7 to control VPP (I have also jumpered VPP from the Motherboard to my PCB).

Putting a scope on the RST pin (also jumpered to my PCB) I can see that the pin goes to 3V just as it should, based upon the schematic.

我也尝试using the P0_4 & P0_5 motherboard pins and run them to my P0_0 & P0_1 pins, just to see if that made a difference. I have tried opening SmartSnippets using just UART and in UART/SPI mode, I even tried JTAG mode.

Something else, I tried disconnecting my PCB completely, then running SmartSnippets. The error is exactly the same, even though no BLE board is connected. This leads me to believe that I don't have something on my PCB connected properly, but if so, why can I run my PCB in debug mode without any issues? Don't they use the same connections for both Debug and OTP programming? (with the addition of the VPP jumper for burning OTP).

Complete list of connections (10) that I currently have:
Motherboard <-> My PCB (pins on DA14580)
--------------------------------------------
P0_4 (TX) <-> P0.0 (ALT_UART_TX)
P0_5 (RX) <-> P0_1 (ALT_UART_RX)
P0_2(CTS) <-> P0_2(CTS)
P0_3(RTS) <-> P0_3(RTS)
VCC_EXT <-> VBAT
GND <-> GND
VPP <-> VPP
SWDIO <-> SWDIO
SWCLK <-> SWCLK
RST <-> RST

Is there any connection that you see that I am missing?

Complete Log Message:
[INFO @15-09-23 12:46:00] Header records have been removed from hex file sps_device.hex.
[INFO @15-09-23 12:46:00] Read 14212 bytes from file sps_device.hex.
[INFO @15-09-23 12:46:10] Firmware File C:\Users\Klim\SmartSnippets\resources\programmer_ES5.bin has been selected for downloading.
[INFO @15-09-23 12:46:10] Connection to COM31 port has successfully opened.
[INFO @15-09-23 12:46:10] Started download procedure...
[ACTION @15-09-23 12:46:11] Please press the hardware reset button on the board to start the download process.
[ERROR @15-09-23 12:46:26] Timeout: Reset signal not detected for more than 16000 msecs.
[INFO @15-09-23 12:46:26] Successfully disconnected from port COM31.
[INFO @15-09-23 12:46:26] Failed downloading firmware file to the board.

Thanks for any input, ---klim
*NOTE-- for some reason, the forum post replaces the string "P0_underscore_0" with the string "****". So I had to edit it to "P0-0" so it would display. Interesting.

MHv_Dialog
Offline
Last seen:2 months 2 weeks ago
Staff
加入:2013-12-06 15:10
Hi,

Hi,

A Dialog representative in your region has contacted you offline for troubleshooting. There are no obvious steps that you have missed as far as I can see from your description.

klim9531
Offline
Last seen:4 years 6 months ago
加入:2015-01-28 23:52
Hi MHv_Dialog,

Hi MHv_Dialog,

Thanks for your reply, I realized that I could test things a little easier from SmartSnippets by reverting my code to debug (from OTP) then just using the file download feature in the Booter utility.

I am getting the same results, my PCB will not allow the download, removing my PCB from the motherboard gives the same error message.

But one step closer to getting it figured out, if I now connect the BLE daughter card to the motherboard (my PCB still disconnected) then I am able to successfully download the hex file to the daughter card.

I will post here when I find a solution, thanks for your help, --klim

klim9531
Offline
Last seen:4 years 6 months ago
加入:2015-01-28 23:52
Hi MHv_Dialog,

Hi MHv_Dialog,

First off, thanks to Dialog for the great support! Mikael at Dialog called me and helped me debug my setup, this was extremely helpful. In particular, having a chance to ask a few key questions about the development environment really helped me to understand what *should* be happening. The nature of the Dialog app notes is that they assume everything will proceed according to instructions. So when things go awry, I am often left scratching my head. But maybe that's just me. Anyway, here is a brief description of what I had previously done, combined with what I learned during the phone call, hopefully I get it right in the retell:

1.以前,你应该用凯尔IDE to build a .hex file for your project. All we will be doing here in SmartSnippets is to point to that .hex file and load it into our BLE chip. But you should know that, before you can burn your .hex file to OTP, you need to change some settings in the DA14580_config file in the root of your project directory. There are several define directives where the name suggests that you would want to change it, but as it turns out (for my chip, at least) the only thing that needs to be changed is the line "#define DEVELOPMENT_DEBUG 1" which needs to be changed to a 0. Some others that can be left as they are: "#undef APP_BOOT_FROM_OTP" and "#undef READ_NVDS_STRUCT_FROM_OTP". Make sure to clean/rebuild your project after making these changes.

2. It's possible (and easiest) to program the OTP using just the JTAG connection through SmartSnippets. This means that a bunch pf the connections that I had jumpered were not necessary, specifically the UART lines P0_4 (TX), P0_5 (RX), P0_2(CTS), and P0_3(RTS). So I disconnected those. Now when you start up SmartSnippets, you should be presented with an 'Open Project/Create Project' screen. If you have not previously tried to use SmartSnippets with your project, then you will need to click "New" and give the project a name, don't worry much about the name you give the project here, all we really care about is that you select the "JTAG" radio button, at which point you should see your JLINK's serial number in the center box. Place a check mark in the JLINK serial number box, select you chip type (mine is the DA14580-01) then hit "Open".

3. Select the OTP icon in the left panel (mouse over them to see what they are) then once there, select teh OTP Image tab and browse to your .hex file (should be in a folder named 'out' in your project). Click the "Connect" button, then, if you are really feeling brave, click "Burn". You should see in the log window that the file gets downloaded, and burning begins (sadly, my project still has problems, which I will describe below).

4. On the OTP Header Tab (if the Tab is not showing, click again on the "OTP Programmer" button in the left panel) first click on "Connect" then click on "Read from Memory". This will read from your chip some values (like XTAL calibration trim) that were already set at the factory. At the top of the window there are two Application Flag parameters, they need to be changed to "Yes". There are a bunch of other values, I was told that I didn't need to change any of them, so I didn't. Part of this is because my DA14580 chip is actually already 'repackaged' by Murata (as I described in an earlier post above) and they have done the work of including an external 16MHz xtal among other things. So my situation might not apply to you, please realize this. So now all you need to do is click "Burn" and you should be done.

Now let me continue with my sad tale, because after following all the above, I am am still not able to program my chip. Dang.

Unfortunately, something didn't go right, but not in a disastrous way. The OTP burn for the main hex file gets all ready to go, then it announces an error (with some really bad spelling in it) and just stops. Fortunately, I had a probe on the VPP line to see if it raised the voltage, that never happened, so I am still able to use the chip in debug mode as I have been doing prior to this. Not sure if that is the problem, that we are not getting 6.8V to my PCB, or if the burn failed before it got to that part.

Here is the log that was generated when I hit 'Connect' then 'Burn'.

(信息@15-09-25 12:17:17] Could not measure total IR len. TDO is constant high.
(信息@15-09-25 12:17:17] Could not measure total IR len. TDO is constant high.
(信息@15-09-25 12:17:17] Found SWD-DP with ID 0x0BB11477
(信息@15-09-25 12:17:17] Found Cortex-M0 r0p0, Little endian.
(信息@15-09-25 12:17:17] FPUnit: 4 code (BP) slots and 0 literal slots
(信息@15-09-25 12:17:17] BTLE device selected.
(信息@15-09-25 12:17:30] Header records have been removed from hex file sps_device.hex.
(信息@15-09-25 12:17:30] Read 14276 bytes from file sps_device.hex.
(信息@15-09-25 12:18:05] Firmware File C:\Users\Klim\SmartSnippets\resources\jtag_programmer.bin has been selected for downloading.
(信息@15-09-25 12:18:05] Cortex-M: Debugger tries to set PC to odd value. Corrected register value from 0x000800B5 to 0x000800B4
(信息@15-09-25 12:18:05] Successfully downloaded firmware file to the board.
(信息@15-09-25 12:19:18] Started burning memory with 14276 bytes of data at address 0x40000.
[ERROR @15-09-25 12:19:18] Adddittional error info at address 0x81FEC (MSB first): FF FF FF FE
[ERROR @15-09-25 12:19:19] Memory burning failed.

Any suggestions that you have for how to test the system further would be greatly appreciated.

Thanks, klim

MT_dialog
Offline
Last seen:2 months 3 weeks ago
Staff
加入:2015-06-08 11:34
Hi klim,

Hi klim,

The most possible reason for this error is probably the OTP programming supply. Can you please check the supply on the VPP and make sure that a 6.8 volts are applied.

Thanks MT_dialog

klim9531
Offline
Last seen:4 years 6 months ago
加入:2015-01-28 23:52
Hi MT_Dialog,

Hi MT_Dialog,

OK, I have the solution to my problem described above, and possibly this was the culprit all along with the original "reset button not working". Thanks again to Mikael at Dialog for helping me get the problem figured out.

In SmartSnippets, the "Board Setup" tab has a selection for "GPIO pin that controls the transistor enabling high voltage..." which defaults to P0_7. Obviously if this is not correctly set then we will not get the 6.8V that is necessary to burn the OTP. ---But--- I/we already knew this, and I had verified in the Murata PCB schematics, that P0_7 does control the 6.8V transistor.

The fatal mistake that I made was then assuming that the P0_7 on the Murata Motherboard was being controlled by SmartSnippets. I was viewing the control flow as starting at SmartSnippets, passing to the FTDI chip on Murata Motherboard, then carrying to the DA14580 on my PCB. Not the case where the OTP burn is concerned.

Turns out, during OTP burn, the P0_7 pin on the Murata motherboard is actually controlled by the P0_7 pin *FROM THE DA14580 ON MY PCB*. So the solution was quite simple, I ran a jumper from the P0_7 pin on my PCB to the P0_7 pin on the Murata Motherboard, and, boom-- I was able to flash the OTP and successfully boot from it.

So my device now functions standalone, and does what its supposed to do. A very exciting milestone, I hope my notes on my struggles will help some other developers get to this point too.

干杯,klim