<re_irc>
It boils down to the fact that we will require a delay of at least 4 clocks of the ethernet reference (50 or 25 MHz) clock between writes to the same registers.
<re_irc>
Does anyone have a good suggestion for how we can implement such a fix? I'm currently thinking of creating an extension trait within "stm32-eth" that adds the required delay (~15 cycles at the max speed of 180 MHz) before each write operation to a register. However, this requires that we explicitly import the PAC (since the extension trait would, AFAICT, have to be on "pac::generic::Reg", which is not re-exported by HALs) for...
<re_irc>
... each of the dependencies. While not an enormous problem, I wondered if there is a nicer solution to the problem.
<re_irc>
< (@datdenkikniet:matrix.org)> Hej all, I have a design question.
<re_irc>
It boils down to the fact that we will require a delay of at least 4 clocks of the ethernet reference (50 or 25 MHz) clock between writes to the same registers.
<re_irc>
Does anyone have a good suggestion for how we can implement such a fix? I'm currently thinking of creating an extension trait within "stm32-eth" that adds the required delay (~30 cycles at the max speed of 180 MHz and 25 MHz "REF_CLK") before each write operation to a register. However, this requires that we explicitly import the PAC (since the extension trait would, AFAICT, have to be on "pac::generic::Reg", which is not...
<re_irc>
It boils down to the fact that we will require a delay of at least 4 clocks of the ethernet reference (50 or 25 MHz) clock between writes to the same registers on STM32F4xx parts.
<re_irc>
Does anyone have a good suggestion for how we can implement such a fix? I'm currently thinking of creating an extension trait within "stm32-eth" that adds the required delay (~30 cycles at the max speed of 180 MHz and 25 MHz "REF_CLK") before each write operation to a register. However, this requires that we explicitly import the PAC (since the extension trait would, AFAICT, have to be on "pac::generic::Reg", which is not...
<re_irc>
< (@datdenkikniet:matrix.org)> +Unconditionally applying the delay wouldn't be a big deal, I think, since most of the register accesses are only during setup. Possibly avoiding depending directly on the PACs would be nice, though.
<re_irc>
< (@orclev:matrix.org)> does anyone happen to know a convenient way to print a vector table using gdb? I can query individual memory addresses, but it would be nice to be able to see all the entries at once.
<re_irc>
It boils down to the fact that we will require a delay of at least 4 clocks of the ethernet reference (50 or 25 MHz) clock between writes to the same registers on STM32F4xx parts.
<re_irc>
Does anyone have a good suggestion for how we can implement such a fix? I'm currently thinking of creating an extension trait within "stm32-eth" that adds the required delay (~30 cycles at the max speed of 180 MHz and 25 MHz "REF_CLK") before each write operation to a register. However, this requires that we explicitly import the PAC (since the extension trait would, AFAICT, have to be on "pac::generic::Reg", which is not...
<re_irc>
It boils down to the fact that a delay of at least 4 clocks of the ethernet reference clock (50 or 25 MHz) between writes to the same registers on STM32F4xx parts is required.
<re_irc>
Does anyone have a good suggestion for how we can implement such a fix? I'm currently thinking of creating an extension trait within "stm32-eth" that adds the required delay (~30 cycles at the max speed of 180 MHz and 25 MHz "REF_CLK") before each write operation to a register. However, this requires that we explicitly import the PAC (since the extension trait would, AFAICT, have to be on "pac::generic::Reg", which is not...
<re_irc>
It boils down to the fact that a delay of at least 4 clocks of the ethernet reference clock (50 or 25 MHz) between writes to the same registers on STM32F4xx parts is required.
<re_irc>
Does anyone have a good suggestion for how we can implement such a fix? I'm currently thinking of creating an extension trait within "stm32-eth" that adds the required delay (~30 cycles at the max speed of 180 MHz and 25 MHz "REF_CLK") before each write operation to a register. However, this requires that we explicitly import the PAC (since the extension trait would, AFAICT, have to be implemented for "pac::generic::Reg", which...
<re_irc>
< (@datdenkikniet:matrix.org)> Hej all, I have a design question.
<re_irc>
It boils down to the fact that a delay of at least 4 clocks of the ethernet reference clock (50 or 25 MHz) between writes to the same registers on STM32F4xx parts is required.
<re_irc>
Does anyone have a good suggestion for how we can implement such a fix? I'm currently thinking of creating an extension trait within "stm32-eth" that adds the required delay (~30 cycles at the max speed of 180 MHz and 25 MHz "REF_CLK") before each write operation to a register. However, this requires that we explicitly import the PAC (since the extension trait would, AFAICT, have to be implemented for "pac::generic::Reg", which...
<re_irc>
<pixelhamster> Hi, is cargo-embed only meant for the weird probe cables ?
<re_irc>
I have recently acquired an Adafruit nrf52480 feather https://www.adafruit.com/product/4062. I'm trying to get a hello world or LED blink rust example running by flashing it over usb.
<re_irc>
I've tried flashing with many tools but I think I lack knowledge around many of them, the device was in bootloader mode (green and red led start shining).
<re_irc>
< (@adamgreig:matrix.org)> Yea, cargo embed doesn't know how to talk to bootloaders, but you can use the normal program for your bootloader to load rust code
<re_irc>
<pixelhamster> I see, thanks for the info :)
<re_irc>
< (@orclev:matrix.org)> pixelhamster: For what's it's worth I hate a ton of problems getting a nRF52840 device with an adafruit bootloader working. I could flash programs and they would run up to a point, but it seemed like the mechanism that's supposed to forward interrupts didn't work. Any time an interrupt was triggered it would result in the device rebooting. Ultimately I connected to it using openocd and a st-link debugger...
<re_irc>
... and just flashed over the boot loader. It can no longer be put into bootloader mode using the reset pin, but I did actually get interrupts working again. If you discover a way to get the adafruit bootloader functioning with interrupts I'd be interested in hearing what you did.
<re_irc>
< (@orclev:matrix.org)> * had
<re_irc>
< (@adamgreig:matrix.org)> It sounds like possibly their bootloader fails to write the vector offset table so you'd have to do that in your firmware
<re_irc>
< (@adamgreig:matrix.org)> It's really something a bootloader should do but some of them are imo defective and do not
<re_irc>
< (@adamgreig:matrix.org)> But it is possible to do that yourself and might have been the issue
<re_irc>
<pixelhamster> what tool did you use to flash it with the bootloader ? I just tried the uf2 thing but other than now making the status led burn bright red it didn't seem to work correctly
<re_irc>
<pixelhamster> * correctly, I used "uf2conv.py hello -c -b 0x26000 -f 0xADA52840" and it gave me a 500kb uf2 file which I dragged to the mounted usb storage device when in bootloader mode
<re_irc>
< (@orclev:matrix.org)> If the docs I was reading are correct, things get funky with the nRF52840 where it has this weird interrupt handler chaining mechanism. There are 2 required pieces and 2 optional pieces. Required are the MBR and Application code. Optional are the bootloader and SoftDevice. The docs seem to indicate that the vector table for the MBR _always_ gets invoked first. It will then inspect the status of various...
<re_irc>
... memory and register locations to determine if a bootloader is present. If it is, it will read the bootloaders vector table and invoke the bootloaders handler if one is set. The bootloader in turn is supposed to look for either the SoftDevice vector table, or your applications vector table, and invoke whichever handler it finds. In the event of it being your application then its handler is invoked and everything is done. In...
<re_irc>
... the event that it's SoftDevice, it will then handle the interrupt if it needs to and if not it will look for your applications vector table and invoke your applications interrupt handler. The whole thing seems sketchy and error prone and obviously something isn't working correctly.
<re_irc>
< (@orclev:matrix.org)> pixelhamster: Very similar, used reset to get it in bootloader mode where it shows up as a USB driver. Built the uf2 file, initially with a base offset of 0x26000 just as you did but never got that working. After playing around with it a while I finally gave up on SoftDevice and set the base as 0x1000 as well as defined a memory map that located the application code at 0x1000 (the space from 0x0 to 0x999...
<re_irc>
... being reserved for the MBR). That _worked_ except for interrupts. Eventually I just used openocd and a st-link debugger, set the memory map back to 0x0 as the base, and flashed it that way. That nukes the MBR therefore breaking the whole interrupt chaining shenanigans they've got going on, but got it working.
<re_irc>
< (@orclev:matrix.org)> Thinking about this more, I think what was getting at might be right. I think I misunderstood the way interrupt handling works, at least as far as the MBR and bootloader are concerned. I think the way it's supposed to work is that the MBR initially boots up, registers the bootloader vector table in the vector offset table then passes control to the bootloader, the bootloader in turn is then _supposed_ to...
<re_irc>
... register the SoftDevice or Application vector table in the vector offset table but doesn't, and then passes control to SoftDevice or your application. If it's SoftDevice it keeps itself registered as the active vector table, but forwards any interrupts it doesn't handle itself. If it's your application then it just handles the interrupts directly. I think what I was doing just prior to overwriting the MBR would have worked...
<re_irc>
... if I had just adjusted the vector offset table register to point at 0x1000.
<re_irc>
< (@orclev:matrix.org)> also something to be aware of is that the adafruit bootloader protects the MBR. As far as I can tell it will refuse to flash a uf2 that attempts to write to memory below 0x1000.
<re_irc>
< (@orclev:matrix.org)> if you keep SoftDevice in flash I think you might be able to get everything working but you'll need to setup your own memory.x file to write your application code to 0x26000
<re_irc>
< (@orclev:matrix.org)> By default the memory.x packaged with HAL assumes no SoftDevice, MBR, or Bootloader and will attempt to locate your app at 0x0
dc740 has quit [Remote host closed the connection]