Author Topic: Gowin: Any faster way to re-program the embedded Cortex-M3?  (Read 884 times)

0 Members and 1 Guest are viewing this topic.

Offline mblinovTopic starter

  • Contributor
  • Posts: 43
  • Country: gb
Hi all,

So the particular Gowin FPGA I have (GW1NSR4C) has an embedded hard Cortex-M3 core. Which is really great, and it works, and I've got debugging and everything rolling now, but...

The way to program the thing with a fresh piece of firmware (NOT bitstream) goes like this:
  • Build your new binary from the Eclipse IDE

  • Open the programmer from the Eclipse IDE

  • Now, we have to put the FPGA JTAG into "FPGA mode" (Explanation in a moment.) This means physically power-cycling the board. I then physically un-plug the J-Link that is currently attached to the JTAG, and attach the Gowin programmer.
  • Now, we scan for devices in the programmer, which it finds, and I select the FPGA from the drop-down list.

  • Double-click on mode, select "MCU firmware erase, program, verify", select by bitstream, select the freshly-built binary image of the firmware. This takes around a minute or so, "only" 10 seconds without verification step.

  • Now, you have to put the JTAG interface into "MCU mode". This is just like the programming step, just a different drop-down selection. This step takes a second to run.

  • Physically un-plug the Gowin programmer, plug-in the J-Link. The FPGA JTAG port is now a Cortex-M3 as far as any onlooker is concerned, until its power-cycled again.
  • Hit "debug" in the Eclipse IDE...

If you try to just re-compile and hit "Debug" straight away, the debug session goes crazy because the ELF file changed, but the underlying bytes at the FPGA's end of the wire haven't. So you've essentially pulled the carpet from under your own feet. The binary on the FPGA hasn't changed - you have to reprogram the thing in full in order to do that.

While I go ahead and build a Rube Goldberg machine to automatically multiplex the J-Link/Gowin programmers and powercycle the board, what do you guys think?
« Last Edit: May 25, 2022, 03:45:56 am by mblinov »
 

Offline mblinovTopic starter

  • Contributor
  • Posts: 43
  • Country: gb
Re: Gowin: Any faster way to re-program the embedded Cortex-M3?
« Reply #1 on: May 25, 2022, 04:15:14 am »
Well, I've just discovered that alongside "programmer.exe", there is also "programmer_cli.exe", which lets you do everything via command line, so the clicky-button problem is solved.

But now I'm thinking, whether I really need to be swapping out the Gowin JTAG adapter and the J-Link JTAG adapter - I don't leave them both physically connected to the FPGA JTAG port at the same time out of concerns for damaging something, but if all the JTAG lines are open drain then that shouldn't be a concern, right?
 

Offline FlyingDutch

  • Regular Contributor
  • *
  • Posts: 144
  • Country: pl
Re: Gowin: Any faster way to re-program the embedded Cortex-M3?
« Reply #2 on: May 25, 2022, 02:15:32 pm »
Hello @mblinov,

I have one question related to using Cortex-M3 core on this board. Did you manage to handle "Hyper-RAM" from this hard-core? Without Hyper_RAM this CPU has only 16 KB of RAM and one can use it only for very basic programs. Did you solve this iisue?

Related to your problem one can use J-TAG programmer to program hard-cpu, but on "Tang nano 4K" external J-TAG programmer is not working. Yes i think that it is "fu.. up".

Best Regards
 
 

Offline mblinovTopic starter

  • Contributor
  • Posts: 43
  • Country: gb
Re: Gowin: Any faster way to re-program the embedded Cortex-M3?
« Reply #3 on: May 25, 2022, 02:39:59 pm »
I confess I haven't played much at all with any of the peripherals - still getting my feet wet with the embedded MPU and its peripherals. 16kB is indeed not much, but I am hoping it might be "just enough" for my application. What I'm more concerned about is the 32kB of flash for the code.

Reading the datasheet for the Hyper-RAM IP, in theory you should be able to write an AHB slave -> Hyper-RAM shim, and then use the linker script to put your heap or data in your AHB peripheral address region. However, the AHB bus seems to be limited to only 10 address bits, so you will only be able to add on an additional 64kB anyway (see image below). Although I suppose you could come up with an elaborate bank-switching system, but that is probably pushing what's practical.



I will probably spin a board soon - I'll see if I can stick one of these Hyper-RAM peripherals on it and test it out.
« Last Edit: May 25, 2022, 02:42:05 pm by mblinov »
 
The following users thanked this post: FlyingDutch


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf