Hi Dialog, my name is Kevin.
So far as I am working, I was able to connect DA 14580 ( using my custom board ) to Smart Snippets,
I have succeeded to burn blinky and other peripheral code, and it's working.
The problem is when I tried to burn ble_app_peripheral , the following message which I attached in this post is appeared
For Antenna Design, I use antenna design referring to page 24 of document an-b-027.
What is causing the problem, and what is the possible mistake from our side?
Is it caused by antenna design, or what kind of fault ?
Attachment:
Device:
Hi Kevleo94,
Seems that he fw ends up at the hardfault handler, and that can be quite a few reasons hardware and software, if you use the ble_app_peripheral as is out of the SDK then the fw isn't one of them and also if the code ends up there the antenna is the least of your worries. Now since this is a custom board and the fw is loaded as is, then most probably the issue lies on your board, try to debug using keil this and check where exactly the hardfault occurs (on which command the execution of the device stalls and ends up in the hardfault handler, perhaps this will give you a clue), also i suppose that this occurs with all the BLE related projects.
Thanks MT_dialog
Hi Mt_Dialog
我尝试使用凯尔,燃烧数据和you see my attachment?
I don't understand what's the meaning of the error, which lead me on asking MT_dialog for it.
I might need your help, to explain to me what's going wrong, and why every non-ble program is able to be burn while ble program is not.
Kinds Regard,
Kevin Leo
Hi Kevleo94,
Yes, i ve seen the attachment, that's how i know that the code ends up in the hardfault handler. The Hardfault interrupt is an M0 interrupt that could indicate system errors, unaligned access to memory, access to invalid Addresses, etc. The SDK examples are operational as they are, so if you are trying to run that fw on a custom board and its not running then the issue is most probably on your board. Identifying a hw issue just by looking that the code ends up in a hardfault condition isn't possible, and that would require hw debugging on the board itself, thats why i promted you to check if possible where exactly the hardfault occurs.
Thanks MT_dialog
Hi, MT Dialog
据我所知从你的解释是一个error caused by hardfault interrupt. When a hardfault interrupt occurs, which pins should I look specifically for?
My custom board meets the requested requirement in tutorial 7, ie vdcdc must be worth at least 1.41v, vdcdc resistance should be 10Mohm, and many more.
Is there any other requirement that must be met to ensure no hardfault interrupt cause the system to be error?
Kinds Regard,
Kevin Leo
Hi Kevleo94,
As mentioned, the hardfault is a generic indication of system error, there are no pins that would indicate an error so that you can assume what to check in order to prevent this from happening. When i mentioned hw issue this is most probably caused by the crystals, you should check XTAL16 and XTAL32 (if you have one and you are using sleep, if you dont have an XTAL32 you will have to switch to RCX if the project you are using has the sleep mode enabled). Please try to identify what is the instruction that is executed and the hardfault occurs (a quick way of identifying this would be to check the PC that the MCU has dumped in STATUS_BASE + 0x18, this will show you the address of the instruction that forced the hardfault to occur, if you can send buck a dump of the entire register set it would help as well). Also are you sure that the project that you are building is for the 580 and not the 581 or the SoC that you have is a 580 and not a 581 ? There is a dropdown box on the toolbar that indicates the build for each chip version, so please double check that.
Thanks MT_dialog