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?

[ChuckRui]

Hi，

I burned light_blub using VSCODE. I also tried burning zephyr's blinky_pwm. After burning it, I measured the LED1 pins and found no PWM output, proving that the program didn't seem to be running on my board. An additional question I would like to ask is if I want to program my board through the Programmer in nRF Connect for Desktop:
1. If I want to burn blinky_pwm, where is the corresponding hex file directory? Is it in this path? E:\ncs\v2.3.0\zephyr\samples\basic\blinky_pwm\build\zephyr.hex
2. I can't find my DK board where it seems to be connected to Programmer software
3. Whether I short-connect VOD and VTG to external boards, which are the same for Programmer software

[Vidar Berg]

Hi,

ChuckRui said:

E:\ncs\v2.3.0\zephyr\samples\basic\blinky_pwm\build\zephyr.hex

You are missing one directory in the path. It should be in E:\ncs\v2.3.0\zephyr\samples\basic\blinky_pwm\build\zephyr\zephyr.hex

ChuckRui said:

2. I can't find my DK board where it seems to be connected to Programmer software

Is your DK not being displayed in the Programmer app?

ChuckRui said:

3. Whether I short-connect VOD and VTG to external boards, which are the same for Programmer software

Yes, the SWD connections need to be the same as when you are programming in VS code.

[ChuckRui]

I have tried burning other routines, such as light_switch and light_blub for matter, blinky and blinky_pwm for basic under zephyr

[Vidar Berg]

Does your board include the 32 KHz crystal? 

[ChuckRui]

That's right. Now that you mention it, I realize my board doesn't have 32kHz crystal.Is that why the program didn't start

[Vidar Berg]

Yes, most likely. In the blinky sample, try to add CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y to the prj.conf file. This changes the clock source to the internal RC oscillator.

[ChuckRui]

Vidar Berg said:

是的，很有可能。在 blinky 示例中，尝试将CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC =y 添加到 prj.conf 文件。这会将时钟源更改为内部 RC 振荡器。

What about "light_blub"? I don't think it matters

[ChuckRui]

Thank you.I added 32k crystal to my own board and found that the app runs normally and the LED lights up, but I haven't tested CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y in prj.conf, I will test it again later, I think it should be OK.

[Vidar Berg]

ChuckRui said:

What about "light_blub"? I don't think it matters

The OS scheduler is configured to use the 32KHz clock. So, if you have selected the wrong clock source (i.e. crystal oscillator on a board that doesn't have a crystal), you will not be able to run any of the examples. 

ChuckRui said:

I have another question, if I burn this zephyr.hex file through Programmer, is the network core and application core burned together? Or if I want to burn them separately, where is the corresponding hex file directory, which I don't know much about

The app core and netcore must be programmed separately. The netcore hex will be located in <build>/<child image>/zephyr/. The name of the child image is hci_rpmsg if you build a regular Bluetooth project.

An overview of the different hex files generated by a build can be found here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/app_dev/multi_image/index.html#what-image-files-are 

[ChuckRui]

Vidar Berg said:

The app core and netcore must be programmed separately. The netcore hex will be located in <build>/<child image>/zephyr/. The name of the child image is hci_rpmsg if you build a regular Bluetooth project.

But as far as I know,according this page:(devzone.nordicsemi.com/.../hex-file-explain-about-5340-development),It says: merged_domains.hex -> Represents the merged image of application core and network core, so I was wondering if the network core and network core could be burned together. And like the light_blub routine I burned, if it's a hex file on zephyr, shouldn't this be the application core along with the network core?