• Content Count

  • Joined

  • Last visited

About buckd

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi, I'm sorry I cannot give the full design, but here are some more notes: I enabled the vauxp4/vauxn4 under 'channel sequencer' in the XADC wizard block, then created two input ports and manually routed them to it. I'm sorry I don't remember how I figured out it was Vaux4 that goes to the single-ended A0 input; it may have been trial and error. I enabled the pins according to the .xdc file here (e.g. ck_an_n[0] and ck_an_p[0]): https://github.com/Digilent/Arty-XADC/blob/master/src/constraints/Arty_Master.xdc#L112 and renamed them to my port names I created above. I hope this helps.
  2. Hi, and thanks for the response. Note that the touching of the FPGA requires no pressure at all - mere contact with the skin seems to do it. Are there tools that exist that can detect possible FPGA damage, mark it, and work around it? Thanks! D
  3. Yep, I take my finger and make slight contact with the top of the chip and a button press is registered. We haven't made block diagram or XDC modifications to our bitstream in quite a while, and just use C code run in the SDK. This was discovered by accident when I felt the chip to see if it was overheating after getting the weird behavior. I can tell it registers as a button press because I have code that is more or less like this: while(1) { while(!buttons_read()); // Wait press // Do stuff while(buttons_read()); // Wait unpress } where 'buttons_read()' is a function that uses the PmodGPIO block to detect a button press. The center code is always run when touching that part of the chip. It's odd because the main application otherwise runs normally, including heavy computations on the microblaze.
  4. Hi, We've been using the Arty quite heavily for various projects, and only recently have I come across some strangeness which may indicate damage. We are using a Microblaze design with several GPIO blocks to control lots of digital I/O. Just today I have noticed: BTN 3 no longer works SW0 operates as a button (and still a switch) Touching the top side of the Artix-7 chip with my finger (little or no pressure) will also be detected as a button This seems like internal FPGA damage and I'm wondering what can be done about it. In Vivado or elsewhere, is there a way to detect the bad innards and perhaps route around them? It is very likely that we shorted something as we are using it to drive a large number of custom digital peripherals. Thanks! D
  5. Hi jpeyron, I am using Vivado 2016.2. So far everything has worked well with the Arty set-up except this one thing. I did just have some success: I created ports 'a0n' and 'a0p' and hooked them into the guts of Vaux4 in the XADC wizard block. I removed all other 'make external connections' except for Vp_Vn. I then uncommented the appropriate constraints from the Arty_master.xdc (renaming ck_an_n[0] to a0n; ck_an_p[0] to a0p). I have not tested other pins, but I'm getting good values from the ADC using AUX channel 4 with single-ended voltages hooked into A0 and using the Arty's GND. I'm not sure if this is the proper way to do it, but so far it's working.
  6. As a follow-up, I manually routed the ck_an_n/p signals (named in the constraints file in the XADC demo) to the Vaux* ports in my block diagram, using the same out-of-order pin mappings. I got a new error this time, in synthesis: [Shape Builder 18-119] Failed to create SYSMON shape for instance design_1_i/xadc_wiz_0/U0/AXI_XADC_CORE_I/XADC_INST. Failed to add instance ck_an_n_IBUF[0]_inst to a new Sysmon shape. The instance already belongs to a shape and its new location conflicts with the one in the existing shape.
  7. Hi and thanks for responding. I did look at the XADC demo and I've been attempting to use the same port names and constraints that it uses in its top module. I still get errors, although I just noticed that the order of the Vaux* ports isn't what I expected for the pins. Tomorrow I will attempt to use the weird order that the top module uses - e.g. Vaux0 goes to A5 (but then the comments say 'Auxiliary Channel 12'?) Is there a reason to the Vaux* to pin mapping presented in that demo file? Thank you!
  8. Hi, I am attempting to read a single-ended analog signal on one of ports A0 through A5 using the XADC in the Arty, but I am unable to connect the proper pins in a Vivado block diagram. Either the bitstream fails, or the C code never reads anything. I have a microblaze design that uses the AXI4 interface to the ADC, but still drives the temperature in the MIG and I followed one person's set-up of the XADC mentioned here, in order to still drive the temperature for the MIG7. I used this guide to do it: http://adiuvoengineering.com/?p=711 I have read everything I could on the matter in the Arty reference manual, but it doesn't mention how to tie these pins in Vivado in the block diagram: https://reference.digilentinc.com/reference/programmable-logic/arty/reference-manual Some things I have tried: I have enabled the Channel Sequencer in the XADC wizard and checked likely channels (like Vaux0, etc.). Doing a 'make external' on these new ports always fails implementation with issues related to improper IOSTANDARD on the bank of ports Manually hooking up the input pins by creating ports, hooking them to the XADC ports (like Vaux0), and using XDC constraints fail to implement with similar errors If I don't do 'make external' on any ports but the Vp_Vn one, then the bitstream generates, but the C code does not read any auxiliary channels. I have properly enabled all of them in the code and I loop through every channel to see what it registers. Temperature shows up just fine Is there a way to properly read the analog pins A0-A5 through the Vivado block diagram? Thanks!