Dear Dialog, I am using a custom DA14580 application board and have four built four samples of it. All work fine with the J-Link debugger. One board successfully runs a modified proximity reporter application very nicely thank you and is able to auto-boot from SPI flash. It gives the same output as when the application is run on the WLCSP module on the Expert Dev kit even though the 32kHz crystal oscillator is not used.The other three boards have the same behaviour in that they all stop running immediately after starting debug. The 16MHz oscillator stops when the function rwip_init(error) is called from arch_main.c. I've tried changing the configuration to use RCX20 instead of XTAL32 but that is not the source of the problem. I cannot see any difference in build level between the four boards that should impact upon the DA14580 operation. Do you have any suggestions what might be causing firmware to stop from within rwip_init() ?
Thanks in advance for any information that you can give.
亲爱的huwjones, wh正确董事会工作en the debugger is not started? Using the debugger will conflict with the sleep modes as most blocks in the DA14580 are powered down to preserve power and as a result the debugger can no longer communicate to the DA14580. (Also see this forum thread on this:http://support.dialog-semiconductor.com/have-close-smartsnippets-get-fir...). Best regards, RvA(Dialog)
Dear RvA, I have not programmed any code into the OTP. The three boards which stop running after calling rwip_init() have not been used with external SPI flash so I have not tried running them stand-alone. I will try loading a program and stopping debug without running. The fourth board - which works as expected - can bootload from SPI flash but I have disabled this for the time being. All boards communicate with the J-Link at 10MHz SW without any problem but the strange thing is why one DA14580 should be running the application just fine and the other three devices all stop at the same point in arch_main.c when debugging. I am hoping that Dialog might suggest some reasons (register settings, header flags, configuration parameters etc) why rwip_init() could cause oscillation to stop - presumably by activating a sleep mode? I could then try and identify any difference between the working DA14580 and the other three.
Appreciate your input. Best wishes
Huw
Dear RvA, I have an update after more investigation. The difference in operation seems to be due to a problem with internal clocks of the DA14580 but I can't track down the cause. Changing CFG_LP_CLK in da14580_config.h is not setting CLK_32K_REG to the expected value of 0x00AA. When select_lp_clk() is executed it just seems to set the XTAL32K_ENABLE bit and clear RC32K_ENABLE. If I explicitly force the value of CLK_32K_REG in main_func() after init_pwr_and_clk_ble() I get the expected value in the register but three chips still lock out if CFG_LUT_PATCH is defined. When this parameter is undefined, there is no lock out at rwip_init() but three boards still do not work correctly - there is no PWM0 output and no BLE advertising packets are issued. When the same code is run on the fourth board, BLE advertising works as expected and a PWM0 output is obtained. I have inspected the registers at 50000000 to 500000fe between the working board and a non-functional one and the only difference I see is in BANDGAP_REG (working = 0x2a69, non-operation = 0x2b20). There is no 32kHz crystal fitted to any board and there should not be any build difference between them in terms of the DA14580 circuit section. Do you have any suggestions ? What might be the clock link between PWM0 and the BLE core ?
Thanks in advance
Huw
Dear RvA, Sorted ... thankfully ! There was a build issue between the functional and threenon-operational boards. These boards had a bad joint at the GND star point so RFIOM was left floating which gave rise to the mysterious lock-up at rwip_init(). The PWM0 output problem was actually due to an unrelated build issue on just one of the three boards so I got led astray there. All four boards are now behaving identically and issuing BLE advertising packets as expected. These were our first off custom boards using the DA14580 so there have been some hardware teething problems to resolve. Thanks, at any rate for Dialog's support.
Dear Huwjones. Good to hear your problems are solved. Thank you very much for sharing your feedback! Best regards, RvA(Dialog)