build another 5340 hardware by 5340dk

[ChuckRui]

Dear devzone：

I short connect VOD and VTG on PCA10095 (5340-DK), and then connect vcc, gnd, clk and cio of another piece of hardware (Dev1) with 5340 as the core board to 5340-DK respectively, and then burn light_blub through vscode. vscode shows that burning was successful, but I tried to add Dev1 to the ipad home app using homepodmini as a bodeer router, but couldn't. There are several problems:
1. I am not sure whether 5340 on Dev1 was successfully burned even though vscode shows it was successfully burned. Is there any other way to test it except on the software application layer?
2. As far as I know, 5340 is integrated with jlink, so does the short-circuitry of VOD and VTG support burning another piece of hardware with 5340 as the core (not 5340Dk)?
2. I used 5340Dk to burn light_blub, which was able to successfully add the device to the home software in ipad (the premise of my test).
3. My basic purpose is to connect a light to P0.28 in Dev1 just like LED2 on 5340Dk, and then adjust the brightness through home software on ipad, is it feasible?

#built successed

#short connect 

[Vidar Berg]

Hello,

To make sure you are programming the nRF on the ext. board, and not the one on the DK, could you try to disconnect the SWDIO/SWDCLK line and see if you are still able to flash without errors? If it still works, then that means you are programming the DK and not your board.

Best regards,

Vidar

[ChuckRui]

Hi Vidar：

I don't think I understand.normally, I build with VSCODE and flash is burned into DK, but when I short-circuit SWDIO/SWDCLK, do the same flash operation, or even rebuild once, it will be burned to the external board, you mean to tell me not to short-circuit and try to burn, To see if it's normal? I think this must be normal because he will burn it into DK. Or I understand wrong, you mean that after short, unplug SWDIO and SWDCLK, this time will be burned to the external board, if this time can still burn normally, it means that I will burn the program to DK. Is that how you understand it?

[Vidar Berg]

Hi,

Maybe I misunderstood what you meant, but I thought you were unsure whether the debugger on the DK was correctly loading the FW image to the external board or if it was programming the FW to the chip on the DK itself.

ChuckRui said:

you mean that after short, unplug SWDIO and SWDCLK, this time will be burned to the external board

I meant to suggest this as a test to verify that the programming fails when you remove the SWD connections. This way you can confirm that you are programming the correct target, at least. 

Have you tried to program other less complex applications to the board to see if they run OK on your board? The Bluetooth peripheral_lbs sample for instance?

[ChuckRui]

I have thought carefully and I understand what you mean. I have also verified it. When I short connected VDD and VTG and unplugged SWDIO and SWCLK, I tried to burn through VSCODE, but the error was shown as below
(Failed to enable coprocessor with unknown error.
[error] [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
[error] [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
[error] [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".)
When I plug in SWDIO and SWCLK, the program can burn normally, I think at least now can prove that the program has been successfully burned into the external board

[Vidar Berg]

Thanks. This means the external board is being programmed. So, the next step will be to find out why the FW fails to run correctly on it. Have you checked if your board works with any of the other SDK examples?