Go Down

Topic: A clear and simple flow (Read 24108 times) previous topic - next topic

famo

What I checked from schematics JTAG is in PA12-PA15 (pins 21-24). JTAG is only between ARM and FPGA. There are place for 10 pin connector or cable buttom side of pcb.


JTAG connection library is in Users\<User_Name>\Documents\Arduino\libraries\VidorPeripherals\src\utility and jtag_host.cpp file

So defined numbers are PA io numbers.
In my jtag_host.cpp I see

#define TMS     28 // PA14             | SERCOM2/ PAD[2]
#define TCK     27 // PA13 -> SPI CLK  | SERCOM2/ PAD[1]
#define TDO     29 // PA15 -> MISO     | SERCOM2/ PAD[3]
#define TDI     26 // PA12 -> MOSI     | SERCOM2/ PAD[0]


What are the numbers 26 ... 29?

Also, I've printed the LED_BUILTIN that I can switch on/off and it is 32.
On the schematic it is on PB08.

What is the formula that gives the pin #define value?



philippe_at_sysemb

#31
Feb 09, 2019, 01:01 pm Last Edit: Feb 13, 2019, 04:11 pm by philippe_at_sysemb Reason: Mistake
Hi all,

if I look in the SAMD21G datasheet PA12, PA13, PA14 and PA15 (TDI, TCK, TDS, TDO) are on pins 21,22,23 and 24.




So board's schematic and SAMD21G datasheet are coherent :)

Now looking in the samd21g18a.h file in the arduino's package PA12..PA15 are define from 12 to 15.

So, and it's of course to be confirmed by arduino's guys , I think it's one right method to associate port number, Pin and #define.


Update : I was wrong : values from 12 to 15  work only with low level jtag functions.
All other arduino's functions have to use values from 26 to 29

famo

Thanks a lot Philippe,
I didn't know about the "Arduino15" folder ... very funny.

So, in your tutorial I see two places where the jtag pins are defined: in jtag.h and in the .ino .

jtag.h comes first, so the winner should be .ino (right?).

Please try to run your tutorial using this #define in the sketch main file

#define TMS     28 // PA14             | SERCOM2/ PAD[2]
#define TCK     27 // PA13 -> SPI CLK  | SERCOM2/ PAD[1]
#define TDO     29 // PA15 -> MISO     | SERCOM2/ PAD[3]
#define TDI     26 // PA12 -> MOSI     | SERCOM2/ PAD[0]

it seems all goes well (or all goes bad but doesn't touch the previuos good programming).

Please let me know, thanks again.

philippe_at_sysemb


Redefining #define is a very very bad practice.   :smiley-sad:
I'm surprised the compiler is not insulting me.
All the jtag functions in jtag.c file haven't visibility with the #define in the .ino file, so they will  used those presents in the "jtag.h"
The correct #define for the JTAG are from 12 to 15. Even if they are the same, thanks to comment my mistake in the .ino file.

PA26 and PA29 don't exist on the SAMD21 pinout, so in best case setting them will have no effect.
For PA27 it's the FPGA's clock send by the SAMD21, so it's better to keep it as output.
And finaly PA28 is the interruption signal send by the FPGA to the SAMD21 when it has,  if I remember well finishes its work (it was planned but I don't know if new libraries implement it).

famo

Redefining #define is a very very bad practice.   :smiley-sad:
I'm surprised the compiler is not insulting me.
All the jtag functions in jtag.c file haven't visibility with the #define in the .ino file, so they will  used those presents in the "jtag.h"
The correct #define for the JTAG are from 12 to 15. Even if they are the same, thanks to comment my mistake in the .ino file.
The redefine was there from beginning as duplicate of that in jtag.h,
I've only changed the numbers, and the compilator gives a detailed warning about them.

So I will delete them and will use the samd21g18a.h  file to know the I/O pins #define.

Just yesterdays I've completed the first version of my project on MKRVidor4000 using your tutorial
as starting point.
It receives short pulses from small cosmic ray detectors performing counting, coincidence and time stamping
all on FPGA, and configuration/readout commands with a simple user interface on the processor.

Thanks again Philippe.


jcristine

if you configure your arduino vidor 4000 as USBBLASTER SAM emulator
you can generate a fpga bistream with altera quartus ( .sof  file ) and upload directly from altera quartus


( and generate arduino code with ttf only at the end of fpga project development)

Can somebody provide steps to "configure your arduino vidor 4000 as USBBLASTER SAM emulator"?

I've been trying for hours.  Maybe I don't understand the use case.  I have Xilinx/Altera Vivado/ISE/Qaurtus experience so I've assumed that if I compile and upload the "USB Blaster" example sketch, the Vidor 4000 board should then enumerate as an Altera USB Blaster so that I can use native Quartus programming tools to upload a bitstreams to the FPGA.

No Luck.  The USB Blaster Sketch compiles and uploads, the board resets and the LED blinks as it should but the Vidor 4000 does not show as a USB Blaster.  It shoes as "MKR Vidor 4000"

Using Win 10, IDE 1.8.8, SAMD Core 1.6.25.

Thank you,

Jeff


tksm372

Hi,

In my case, I uninstalled the driver and re-connect the usb plug, then unknown device was appeared.
After that, I updated its driver and manually chose the "Altera USB-Blaster" (ver. 2.12.0.0), then it works fine.

https://github.com/vidor-libraries/USBBlaster
"windows trying to load the original Altera driver (which does not expose a composite interface).
Fix: uninstall the original driver before plugging in the board"
Minatsu Tukisima

jcristine

"I uninstalled the driver and re-connect the usb plug, then unknown device was appeared."

I have no driver installed.  When I plug the Vidor MKR 4000 board in is appears as "Arduino MKR Vodor 4000", not "unkown device"

Thank you,

Jeff

jwestmoreland

#38
Feb 12, 2019, 03:30 am Last Edit: Feb 12, 2019, 03:39 am by jwestmoreland
jcristine,

I have this working - I am not sure what your issue may be.  (I've switched to using the actual USB-Blaster (II) for all of this.)

Please do a complete uninstall of all FTDI drivers - VCP and D2XX - and reinstall those.

Go to the FTDI site and make sure you have the latest:

https://www.ftdichip.com/Drivers/VCP.htm

To be completely thorough, uninstall, reboot, then reinstall.

I've definitely got this working - on both a Win10 machine and a Win7 laptop - but I also have the USB-Blaster I & II as mentioned above (from past projects).

Edit:  Of course, this is SAM Atmel USB - so, downloading the latest SAM-BA stuff may help.
Sorry - wrong board.

The machine(s) I use have the (complete) Atmel tools installed - could explain why I didn't have any issues. 

Install the SAM-BA and Microchip IDE's if you still have trouble (Atmel was purchased by Microchip).  All downloads are 'free' - initially anyway - what's needed here is definitely free.

YAE:  I'm going to install everything on a new machine - if I see this problem - I will post the procedure I did to resolve it.

HTH,
John W.

famo

So I will delete them and will use the samd21g18a.h  file to know the I/O pins #define.

Big problem if I use the pin #define in samd21g18a.h  file!

The only way to have a working pin #define if I want to use the shield connector pins
A0..A6, D5 (marked as -5 on the connector)
is the following:

#define SCLK     A0                          //  pin A0 on the connector
#define SDATA_IN_TO_FPGA   A1        // pin A1 on the connector
#define SDATA_OUT_TO_PROC A2       // pin A2 on the connector
#define READ_FROM_FPGA      A3       // pin A3 on the connector
#define WRITE_TO_FPGA_ENABLE A4  // pin A4 on the connector
#define TRIGGER A5                         // pin A5 on the connector
#define TRIGGER_RESET  A6              // pin A6 on the connector
#define globalReset  5                      // pin -5  on the connector

Using tha above defines I can operate and check by an oscilloscope
each pin, setting it to 1 and to 0.

If I use the defines from samd21g18a.h file, looking at the schematic

#define SCLK     2                            //  pin A0 on the connector, PIN_PA02
#define SDATA_IN_TO_FPGA   34        // pin A1 on the connector, PIN_PB02
#define SDATA_OUT_TO_PROC 35       // pin A2 on the connector, PIN_PB03
#define READ_FROM_FPGA      4         // pin A3 on the connector, PIN_PA04
#define WRITE_TO_FPGA_ENABLE 5    // pin A4 on the connector, PIN_PA05
#define TRIGGER     6                       // pin A5 on the connector, PIN_PA06
#define TRIGGER_RESET  7               // pin A6 on the connector, PIN_PA07
#define globalReset  43                     // pin -5  on the connector, PIN_PB11


So, what are the "magic" numbers of the working defines?
(decimal values)
                                                               
A0 = 15                                                                         
A1 = 16                                                                         
A2 = 17                                                                         
A3 = 18                                                                         
A4 = 19                                                                         
A5 = 20                                                                         
A6 = 21 

As bonus the LED_BUILTIN that should be attached to processor
 PB08 --> #define PIN_PB08   40  /**< \brief Pin Number for PB08 */
but results to be defined as 32

LED_BUILTIN = 32

With the defines from samd21g18a.h file,
after the program upload the usb communication with MKRVidor4000 doesn't work
anymore, for successive programming and with my terminal emulator.
I can see the usual USB COM port comes up after boot but:
- the terminal emulator hangs at startup and doesn' open its window
- If I want to upload another program, first I have to reprogram the bootloader
using the onboard reset button double-click

Maybe I'm wrong, so I ask here is someone of you has developed a program using the
shield pins and how he has defined the pins.







tksm372

"I uninstalled the driver and re-connect the usb plug, then unknown device was appeared."

I have no driver installed.  When I plug the Vidor MKR 4000 board in is appears as "Arduino MKR Vodor 4000", not "unkown device"
Today I tried on another PC in which Quartus lite 18.1 is also installed.

As you said, "Arduino MKR Vidor 4000" (with a small alert icon) was appeared in the device manager, but at the same time, additional COM port was also appeared. I think it means the device is enumerated and recognized as a composite device.

Then I manually update the driver of "Arduino MKR Vidor 4000" by the following steps:

1. right-click the "Arduino MKR Vidor 4000" and click "Update driver software..."
2. choose "Browse my computer..."
3. choose "Let me pick from a list..."
4. all device categories are listed, select "Show All Devices", and click "Next"
5. click "Have Disk..."
6. click "Browse..." and choose "C:\intelFPGA_lite\18.1\quartus\drivers\usb-blaster\usbblstr.inf". Click "OK".
7. models are listed, choose "Altera USB-Blaster", and clisk "Next".
8. a compatibility warning is appeared, but click "Yes".

Finally "Altera USB-Blaster" came out on the device manager.

Please note that step 4 is important. When I chose a category other than "Show All Devices", the .inf file was rejected at step 6.
Minatsu Tukisima

jwestmoreland

#41
Feb 12, 2019, 11:59 am Last Edit: Feb 12, 2019, 12:07 pm by jwestmoreland
jcristine,

On a new machine - all I did was install the arduino nightly build - and I have a USB Blaster (I) and MKRV4K - installed the lib(s); and downloaded the USB Blaster sketch.

Now - both are showing -
Other Devices:
          Arduino MKR Vidor 4000
          USB Blaster

Installed Quartus programming tools:
          Pointed USB Blaster to update driver here:
C:\intelFPGA\18.1\qprogrammer\drivers\usb-blaster

That worked OK.

To be continued....
Edit:  Minatsu Tukisima above has answered - that's the best procedure.

Regards,
John W.

jcristine

@tksm372:

This:

1. right-click the "Arduino MKR Vidor 4000" and click "Update driver software..."
2. choose "Browse my computer..."
3. choose "Let me pick from a list..."
4. all device categories are listed, select "Show All Devices", and click "Next"
5. click "Have Disk..."
6. click "Browse..." and choose "C:\intelFPGA_lite\18.1\quartus\drivers\usb-blaster\usbblstr.inf". Click "OK".
7. models are listed, choose "Altera USB-Blaster", and clisk "Next".
8. a compatibility warning is appeared, but click "Yes".

WORKS PERFECTLY - Thank you!

It's been years since I've had to install a driver from a ".inf" file and I don't think that I've ever had to do it on Win 10 so with your help, and STEP 4, it works and now Quartus can see the Mkr Vidor 4000 as a Altera USB Blaster so I expect that I can upload VHDL bitstreams directly to the FPGA (I'm not done with the first test yet.)

Prior to this I was just pointing to the drivers folders and checking "include sub-folders" -- that does not work.

Arduino Folks:  it may be wise to copy and paste "tksm372" into both the usb blaster sketch as well as the GitHub page.  It would have saved me hours of frustration.

Thanks again.

Jeff

tksm372

@tksm372:

This:

1. right-click the "Arduino MKR Vidor 4000" and click "Update driver software..."
2. choose "Browse my computer..."
3. choose "Let me pick from a list..."
4. all device categories are listed, select "Show All Devices", and click "Next"
5. click "Have Disk..."
6. click "Browse..." and choose "C:\intelFPGA_lite\18.1\quartus\drivers\usb-blaster\usbblstr.inf". Click "OK".
7. models are listed, choose "Altera USB-Blaster", and clisk "Next".
8. a compatibility warning is appeared, but click "Yes".

WORKS PERFECTLY - Thank you!
Thank you for your report.
I am glad that it worked well :)
Minatsu Tukisima

famo

I reiterate my post, perhaps it is appeared in a wrong place.


-------------------------------------
Big problem if I use the pin #define in samd21g18a.h  file!

The only way to have a working pin #define if I want to use the shield connector pins
A0..A6, D5 (marked as -5 on the connector)
is the following:

#define SCLK     A0                          //  pin A0 on the connector
#define SDATA_IN_TO_FPGA   A1        // pin A1 on the connector
#define SDATA_OUT_TO_PROC A2       // pin A2 on the connector
#define READ_FROM_FPGA      A3       // pin A3 on the connector
#define WRITE_TO_FPGA_ENABLE A4  // pin A4 on the connector
#define TRIGGER A5                         // pin A5 on the connector
#define TRIGGER_RESET  A6              // pin A6 on the connector
#define globalReset  5                      // pin -5  on the connector

Using tha above defines I can operate and check by an oscilloscope
each pin, setting it to 1 and to 0.

If I use the defines from samd21g18a.h file, looking at the schematic

#define SCLK     2                            //  pin A0 on the connector, PIN_PA02
#define SDATA_IN_TO_FPGA   34        // pin A1 on the connector, PIN_PB02
#define SDATA_OUT_TO_PROC 35       // pin A2 on the connector, PIN_PB03
#define READ_FROM_FPGA      4         // pin A3 on the connector, PIN_PA04
#define WRITE_TO_FPGA_ENABLE 5    // pin A4 on the connector, PIN_PA05
#define TRIGGER     6                       // pin A5 on the connector, PIN_PA06
#define TRIGGER_RESET  7               // pin A6 on the connector, PIN_PA07
#define globalReset  43                     // pin -5  on the connector, PIN_PB11


So, what are the "magic" numbers of the working defines?
(decimal values)
                                                               
A0 = 15                                                                         
A1 = 16                                                                         
A2 = 17                                                                         
A3 = 18                                                                         
A4 = 19                                                                         
A5 = 20                                                                         
A6 = 21 

As bonus the LED_BUILTIN that should be attached to processor
 PB08 --> #define PIN_PB08   40  /**< \brief Pin Number for PB08 */
but results to be defined as 32

LED_BUILTIN = 32

With the defines from samd21g18a.h file,
after the program upload the usb communication with MKRVidor4000 doesn't work
anymore, for successive programming and with my terminal emulator.
I can see the usual USB COM port comes up after boot but:
- the terminal emulator hangs at startup and doesn' open its window
- If I want to upload another program, first I have to reprogram the bootloader
using the onboard reset button double-click

Maybe I'm wrong, so I ask here is someone of you has developed a program using the
shield pins and how he has defined the pins.

-------------------------------------

Go Up