Closed Lefix2 closed 4 years ago
Hi Felix, that's great! We got stuck adding USB support to the project last year and left it at this.
I checkout your branch and ran make in the main folder. After download and unzip of the SDK, I get an error patching.
patch -p0 --binary < nRF5_SDK_15.3.0_59ac345.patch (Stripping trailing CRs from patch.) patching file nRF5_SDK_15.3.0_59ac345/integration/nrfx/legacy/nrf_drv_clock.c Hunk #1 FAILED at 38. 1 out of 1 hunk FAILED -- saving rejects to file nRF5_SDK_15.3.0_59ac345/integration/nrfx/legacy/nrf_drv_clock.c.rej make: *** [nRF5_SDK_15.3.0_59ac345] Error 1
Could you check the patch please?
No problem from my side, It’s perhaps your patch version....
Nordic stack use windows formated lines returns
Can you try to change -p0 to -Nup0?
What's the relation to libdvdnav? :) I've tried to recreate the patch and get the same error. I'll continue another time. After changing the include, it compiles. I now need to find one of my pca10059 dongles - I only find the large dev kits (nRF51 DK, nRF52DK, nRF52480 DK). I guess the USB part should also work on the nRF52840 DK and be better then using the limited UART.
I've forgot to click on "update comment"^^ There's absolutely no relation i was reading a thread and i inverted names :) Try -u (for unified)
I'm using Ubuntu 18.04.2 LTS How do you usually apply patches?
can you try tab2space -unix -t2 nRF5_SDK_15.3.0_59ac345.patch
before applying patch?
I've think of something, can you check your write access on nRF5_SDK_15.3.0_59ac345/integration/nrfx/legacy/nrf_drv_clock.c?
I'm sure I have full permisssions: the make file just unzipped it. You don't need to spend time on this. I'll figure it out, just deep inside Bluetooth Mesh - we're looking towards some kind of alpha version. Maybe I can do a better search for the dongles tonight...
Ok, I got the patch to work. I've tried
patch -up0 < $(NRF5_SDK).patch
and the attached patch - I've only added the extra #include
nRF5_SDK_15.3.0_59ac345.patch.zip
With that out of the way, I finally found my pca10059 dongles. will try next.
Next step. Compiled and flashed using J-Link, TagConnect and Ozone. Now, I get a HardFault in trasnport_init()->app_usbd_serial_num_generate(). Did not look into the details. Any ideas?
Ok the patch worked for me I updated repository! No idea! Have you installed MBR? It will not boot without but just in case... Can you try to flash it using nRFConnect?
By the way i compiled with: arm-none-eabi-gcc (GNU MCU Eclipse ARM Embedded GCC, 64-bit) 8.2.1 20181213 (release) [gcc-8-branch revision 267074]
hi. what's MBR? The code reaches main and crashes in transport_init(). Do you have J-Link (or can use the J-Link from other nRF dev kits)? (so I don't need to learn other tools...)
The idea would be to be as minimal as possible, so e.g. we want no dependency on the SoftDevice.
MBR is launched by bootloader then launch app, that's why in the .ld file code is starting at 0x1000. For your case try to change this line to 0x0000
nRFConnect is just a GUI tool to flash dongle using bootloader (no J-Link required). We mostly use STM so we don't have J-Link probes, i'll see to use a DK.
Hi Felix. I'm picking this up again - and did read up on the MBR stuff. It looks like it doesn't hurt and would allow people without an external debugger to upload firmware, so that's a good thing to have. I've tried with a fresh dongle (with MBR intact) and flashes with Ozone. Now, it still gets stuck in transport_init(), but I'll also try with other tools, e.g. without Ozone...
Hi matthias, happy to see you back on this :) Did you try with nrfConnect? It will be a good start. I don't have time to work on flashing with other tools for now (but i use dongles a lot :) ) I'm not really familiar with nrf, which version of dongle do you have? Mines are v1.1.0 (2019.19) The only "bug" I can report is:
Good idea about using nrfConnect. I've used it with J-Link to re-flash MBR + Bootloader, then used USB DFU to upload Raccoon, and hurray, it worked!
One dongle stopped working and I'm irritated why I cannot use J-Link for flashing, but I'll do some tests and record behaviour to figure out.
I've seen the USB getting stuck, too. Here, Ozone + RTT could be helpful to debug this.
Im' able to see device in dfu mode with nrf connect but not with dfu-util, how do you succeed in that?
I don't understand. I've only used nrf connect so far and I had to press RESET button to get it into dfu mode.
...
Ah.. I've used nRF Connect with Dongle in DFU mode (pressing RESET button)
However, I've tried on nRF 52840 DK (pca10056) and it stopped to work. I don't know yet why. I'll probably merge & test your commits one-by-one to find out what causes it.
Oh ok I thought that you used DFU mode standalone! So what i understand is that you used nrfConnect to flash with J-Link?
What i've tried is to see device as common dfu device to flash it using dfu-util and prevent use of any other tool.
That was my one of my fears. I moved uart direct calls to a more generic transport module to change transport regarding hardware. I could be a good thing to check which files are compiled. I returned the pca10056 that had been given to me so i can't debug by myself.
Yes, I've first used nRFConnect with J-Link to flash MBR + Bootloader, then I've un-plugged J-Link and used nRFConnect with USB Dongle in DFU mode to flash Raccoon. I'm still curious why I cannot just use Ozone to flash and debug raccoon.,
Nevertheless: everybody can use nRFConnect and it's beginner-friendly for a one-time use - that's perfect for Raccoon,
No worries, It should not be hard to find the problem with pca10056, the transport module is a good/clean approach (and we had it on the 'nice to have' list..)
So you flashed bootloader and MBR! It's really strange that you can't flash raccoon... If you compare addresses between nrfConnect and J-Link flasher (i don't know the name, Openocd?) you don't notice any difference?
Have you the swd pinout? I'll take time this afternoon to try to connect a stlink on a dongle.
The USB Dongle has a 10-pin TagConnect interface, 10 test points on the bottom and 3 holes for alignment. Without the TagConnect cable, that's no fun - there's a slight chance that SWD lines are also on the outer connectors.
Nevertheless, I'll look into the STM32WB55 flash code (BTstack) to see if that's good and then come back to Raccoon to fix the regression with UART nRF boards.
I didn't know these connectors, they seem pretty reliable. I'll ask to buy one of these expensive copper/plastic part.
If you do, also order the little holder to have it stay fixed to a board - the idea is that you have zero cost for the device, but still have a full JTAG port available (with expensive connector).
On 11 Dec 2019, at 13:06, Lefix2 notifications@github.com wrote:
I didn't know these connectors, they seem pretty reliable. I'll ask to buy one of these expensive copper/plastic part.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
Ok. I did go through your commits. The UART transport did miss the include
I've updated the readme and the nRF SDK patch again and merged it onto master. Please check it out.
I'm still not able to debug on the pca10059, however, I've moved the code start back to 0x0000 and used Ozone to run it on the pca100556 board to figure out why it hangs on re-connect. It was really easyl in the debugger... fixed!
Tried on pca10059 on my side, working like a charm!
Added support for nrRF52840 dongle. I may have introduced bugs for other boards i don't have, it would be great to test them. I did not look at the bit rates at 2Mb, it will be for future improvements.