Hi , dialog
There is an unexpected BOD reset on our designed board . And it's most probably due to a hardware problem. But we can't find any clear deficiency both on PCB layout and SOC assembly . Can you give us some advice . Attachment is our hardware relative files, including pcb file and assembly photo.
Device:
Hi guixiang,
I suppose that the issue is related with this posthttps://support.dialog-semiconductor.com/forums/post/dialog-smartbond-bl...so it is an actual BOD reset on the 1V8 rail, can you please confirm? (can you please also verify that all the voltage rails are measured and only the 1V8 rail is excluded when the device opoerates normally, you can also check the BOD_STATUS_REG in order to be sure that when the BOD happens is due to 1V8?). I ve send your pictures to our hw experts. The report from the hw expert mentioned that we cannot be certain about the assembly from the pictures. On a first look it seems ok, the solder on the left pads seems a bit odd, but it is not a 100% prove that the soldering went well or bad, since removing the device might have caused this, but in general it is not looking too bad. Some additional comment on the design, the decoupling caps are quite far away, and the ground connection is not done through close by vias. You mentioned that you have probed the 1V8 rail and you haven't noticed any significant difference, can you please share the measurement ? An oscilloscope picture showing VDD 1V8 and V33 probed close to the chip at the moment that the reset occurs.
Thanks MT_dialog
hi, MT
In that post(https://support.dialog-semiconductor.com/forums/post/dialog-smartbond-bl...) ,you said " if you disable the DCDC (dg_configUSE_DCDC, this is enabled by default in the bsp_defaults.h) and leave the BOD enabled are you still able to reproduce the issue ? By default when operating in sleep mode the device switces to DCDC when eventually goes to sleep after the 8 seconds, If not then your issue should be an assembly problem on ground of the DCDC pin GND_BUCK. .." And we have done test by disabling DCDC and found no BOD reset. Can this prove that it is not an actual BOD reset ? And we can't see any obvious voltage drop in relative power rail with oscilloscope .
Hi guixiang,
Yes, what you ve done most probably proves that, but its always good to examine an issue and check multiple points in order to verify the issue, from the pictures that you have attached the hw team cannot give you any recommendations regarding your assembly procedure, and also by checking the voltages over an osciloscope my give us some more insight to the issue.
Thanks MT_dialog
Hi MT,
The Attachment is relative power rail osciloscope picture. thanks!
Hi guxiang,
I dont see anything wrong with the voltage, but what about the BOD_STATUS_REG, please check that and check if any of the enabled rails is set to 0 in the BOD_STATUS_REG when the device restarts. You should check this before the BOD is re-enabled after the reset, that means that you would have to trap the fw in SystemInit() in a while loop before the device resets the BOD register ( before hw_cpm_configure_bod_protection() runs) in order to be able to attach and read the BOD_STATUS_REG.
Thanks MT_dialog
嗨,太
I put the test code in SystemInit() function like this:
static void system_init( void *pvParameters )
{
BodStatusRegValue1 = CRG_TOP->BOD_STATUS_REG;
/* Prepare clocks. Note: cm_cpu_clk_set() and cm_sys_clk_set() can be called only from a
* task since they will suspend the task until the XTAL16M has settled and, maybe, the PLL
* is locked.
*/
cm_sys_clk_init(sysclk_XTAL16M); // def: sysclk_XTAL16M
.....
BodStatusRegValue2 = CRG_TOP->BOD_STATUS_REG;
OS_TASK_DELETE(OS_GET_CURRENT_TASK());
}
Sometimes BodStatusRegValue1 is 0x15 , sometimes is 0x13 . But BodStatusRegValue2 is always 0x17.
Check the BOD_STATUS_REG in the SystemInit() function of the system_ARMCM0.c file, as mentioned in my previous post, not in the system_init() function, in the function where you check the BOD status register the BOD has allready been reset by the fw, so you wont be able to see a valid source of what caused you the reset. Check if by reading the status register at that function you get different BOD reasons.
Thanks MT_dialog
嗨,太
这次我把代码放在SystemInit()之前e hw_cpm_configure_bod_protection() runs:
void SystemInit(void)
{
...
BodStatusRegValue1 = CRG_TOP->BOD_STATUS_REG;
/*
* Activate BOD protection (only for AD; for AE is already enabled by the bootloader).
*/
if ((dg_configUSE_BOD == 1)
&& (((dg_configBLACK_ORCA_IC_REV == BLACK_ORCA_IC_REV_A)
&& (dg_configBLACK_ORCA_IC_STEP == BLACK_ORCA_IC_STEP_D))
|| ((dg_configUSE_AUTO_CHIP_DETECTION == 1) && CHIP_IS_AD))) {
hw_cpm_activate_bod_protection_at_init(); // Use BOD
}
...
}
And I got the same result: BodStatusRegValue1 is 0x13 or 0x15 after BOD reset happened.
Hi guxiang,
It seems that you are getting different BOD results in every reset, if that is the case then the only thing i can assume is what i initialy stated regarding the assembly and the DCDC ground soldering (there are no voltage drops on the lines, that is why you dont see anything on the oscilloscope, but if there is bad grounding of the buck DCDC ground pin the BOD will lose reference and will act as soon as the DCDC gets activated). As mentioned, from the pictures that you have attached our hw team cannot assume if there is an issue with the soldering, the only way to check this is using X-rays in order to determine if there is anything wrong with the assembly, also please make sure that you follow the assembly guidelines mentioned in a previous post (AN-B-061 DA1468x Application hardware design guidelines).
Thanks MT_dialog