I have designed a circuit in which I am using STM32L452RETx micro-Controller on PCB. This is basically a current sensor. I am using JTAG-20 connector for debugging. I am using Atollic TrueStudio IDE.
The issue is when I debugg program in TrueStudio by selecting JTAG option in debug configuration then it gives error saying failed to initialize the ST-Link and target not found but when I Select SWD then there is no error and it programs successfully. where as in STM32CubeMx I have set debug to JTAG 5 pin configuration as i am using JTAG 20 in hardware. (serial peripheral-> Sys -> Debug-> Jtag 5 pin). program is debugging without errors but no output at the serial terminal. serial terminal gives no hand shake error.
Can anybody tell is this right way of debugging ( SWD in TrueStudion and JTAG in STM32CubeMx) or I am making a mistake.
Regards,
The paradox is not as big as it seems:
As you can verify in the
Datasheet for STM32L452xx, DS11912 Rev.5, pages 74/75, the alternate functions of the GPIO used for JTAG and SWD are the same (always AF0, "SYS_AF").
Therefore, SWD connetion works after you configured your STM32CubeMX to JTAG (If you had configured your Cube project to SWD, JTAG wouldn't have worked because the JTDI pin (PA15) wouldn't have been connected to AF0.).
This solves the problem why SWD worked unexpectedly.
The problem why JTAG doesn't work remains.
You mentioned that you're using a JTAG-20 connector, but not which ST-Link version exactly you are using. If, for instance, you are using the ST-Link part that is embedded to a nucleo board (or discovery, or similar product of other vendors), the ST-Link pinout is limited to lines needed for SWD and SWO (together: SWV).
This is not due to limitations of TrueStudio, which does support JTAG in principle, but because one of the 5 lines may be unconnected.
Please inspect which exact ST-Link version you are using (easiest thing to check is what the ST-Link Utility program tells you), re-check your schematics and wiring from the target µC to your debug adapter.
If you don't find an obvious reason (and fix your problem this way), your problem may be an electronic one. Then it is off-topic here and (after narrowing it further) you should describe the remaining problem in Electrical Engineering Stack Exchange.
If you have an oscilloscope, it may be worth to check the signals, especially on those pins that are only on JTAG but not SWD (JTDI, JTDO, NJTRST).
Related
I am trying to install android studio in my ubuntu system.But when I open the AVD manager it shows following warning message
after searching on internet I understand that I need to goto bios setup->advanced->intel virtualization technology(enable it if it is disabled),
but I can't find intel virtualization technology option in my bios setup.
bios menu
how can I solve this issue?
It seems that your board doesn't support VT-x. You are looking at the right spot I beleive. I must say, it has been a long time since I've seen such a board.
Have you correctly checked if your board supports VT-x ? Best way to find out is to check the specs of your computer/motherboard online.
Keep us posted, and good luck,
Clovel
EDIT : AMD-V / AMD IOMMU
It seems here that for AMD processors, the option you are looking for is AMD-V (VT-x counterpart) & AMD IOMMU (VTd counterpart ?). See if you can enable either one of these options in Advanced -> CPU Options
I'm creating a blank project for a STM32F103 microcontroller using STM32CubeMX. Using HAL drivers (the default), I got a blinky example working pretty quickly, but I'd like to try out LL (low level) drivers instead of HAL.
When I go to Project > Settings > Advanced Settings in CubeMX, I see the peripherals listed, and there is a pulldown next to each one which only has one option, HAL. According to the docs this is where I could select LL or HAL for each peripheral.
How do I enable LL drivers in STM32CubeMX?
Details: I did a clean install of STM32CubeMX (4.23.0) on Ubuntu (16.04) and created a new project for STM32F103C8 microcontroller (this is on a "Blue Pill" board). I'm using SW4STM32 IDE, everything more or less worked out of the box except I had to select STLink V2 instead of V2.1 in a config file.
from project manager under advanced setting
from driver selector you can change HAL to LL for all peripherals
Currently (STM32CubeMX v4.23.0) the LL drivers are only generated for L1, L4, F2, F4, F7 series. See the chapter 6.2 STM32Cube code generation using Low Layer drivers
For STM32L1, STM32L4, STM32L4+, STM32F2, STM32F4 and STM32F7 Series,
STM32CubeMX allows generating peripheral initialization code based either on the
peripheral HAL driver or on the peripheral Low Layer (LL) driver.
http://www.st.com/content/ccc/resource/technical/document/user_manual/10/c5/1a/43/3a/70/43/7d/DM00104712.pdf/files/DM00104712.pdf/jcr:content/translations/en.DM00104712.pdf
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 years ago.
Improve this question
Spent a couple hours this evening on the #openbsd irc channel troubleshooting a display issue. Couldn't figure this one out though we had fun trying!
Specs:
USB Stick and Openbsd 6.2 Image
Known good,
Openbsd image installed successfully from this USB, to a virtual env on a separate device, using these instructions
Desktop computer
Motherboard, 64bit Intel processor
On-board graphics only
Currently running Ubuntu 16.04.03 Server
BIOS (legacy enabled) set to boot USB first
Monitor
40" Toshiba LCD TV Model 40UX600U
Symptoms
Start computer on Ubuntu server, displays just fine, no issues
Boot to Openbsd USB stick, bios screen runs, self check passes then monitor displays "Unsupported Video Signal". This is not an Openbsd message, but rather from the monitor itself.
Done so far
Cleanly formatted USB (under supervision)
Installed from USB to virtual env on separate device, no issues, loads Openbsd just fine.
Boot computer to Ubuntu, display works perfect
Boot computer to Openbsd USB, display shows error message above.
Unplug and replug VGA cable
Power off, power on monitor
Suspicions
- Pg. 88 of the Toshiba monitor manual shows a table of Acceptable Signal Formats for PC IN. My hunch is the graphics driver is incompatible with this monitor.
Questions
Is there anything I can do to make this monitor work with a new Openbsd 6.2 install?
How can I check Openbsd monitor compatibility before embarking next time?
Ubuntu has KMS support for the nVidia graphics card but OpenBSD only has support for the old UMS driver. The OpenBSD kernel (probably, I'm not sure) is using 640x480 as resolution and the Linux kernel is using the highest resolution supported by your monitor.
You have two options to "fix" the problem. Install OpenBSD on another computer or with a different monitor (you can also use a laptop with a USB<->HDD adapter), when the installer ask if you want graphics support (or something like that, I don't remember), reply yes. Finish the installation and reboot. Then move the HDD to the original computer and power on the machine. You will see the same message but at some point the system will run xenodm (a graphical launcher for X11 sessions, like xdm), then the monitor will work fine. Unfortunately, you can't see the console messages.
Don't change xorg.conf, your problem is not only related to the monitor. Another option (quite better, imho) is to buy a cheap used ATI graphics card and just install OpenBSD. The ATI graphics cards are fully supported (except the newest ones) and have KMS support. You will only see the message during two or three seconds and after of that, you will see the console. Maybe you will need run the installer on a different computer or with a different monitor, but everything will work fine after of that.
Anyway, OpenBSD uses only a standard mode for the basic console. It doesn't make weird unsupported things. So, probably your monitor has some kind of problem with the lowest VGA resolution/frequency. The problem is that the OpenBSD kernel can't change to a higher resolution during the boot process because it doesn't support the nVidia cards at the kernel level. It uses a userland driver for the nVidia cards, like the Linux/BSD/Unix traditionally used to use.
If you have an old (like 10 years or so) Linux LiveCD/installer, try to run it on your computer. You will see the same problem.
Update 1:
Hi friends, could you please recommend me a powered USB hub in Australia(preferred in Melbourne)? I guess my problem is caused by the insufficient power supply.
Hi friends,
I have a FEZ Hydra Basic kit. I got it in 2012 (might be in Sep).
Today I downloaded the latest SDKs, drivers and everything(NETMF and Gadgeteer Package 2014 R1). (.NET Micro Framework 4.3 and the firmware I have on my laptop is 4.2.6.2)
But the firmware on my deivce is 4.1.x.x(I was lucky to saw the device's firmware version just once and I followed the instruction on the software FEZ Config, but failed with errors).
After that, I cannot get the Device's firmware version any more.
I found changing USB ports sometimes help. I have 4 USB ports, some of them can connected to the device, others are not.
So I have no idea to update the firmware in other way.
Could someone please help me to figure out how to find a way to update my firmware?
In the attached image, it shows: the FEZ Config detected the FEZ Hydra and was trying to get the device's firmware version, but it failed to do so and followed by an error message say: Failure - Device is not connected or not responding.
As I mentioned above, I was lucky to see the FEZ Config successfully got the device's version only once.
So my guess is - is it because the output power is not strong enough to support the operation, so I have to use something like a USB hub which has a strong and stable power?(I saw someone mentioned this and cannot find the comments any more).
Bt the way, all USB ports I mentioned above are directly on my laptop which means they get power directly from motherboard, so they should have strong and stable power to support my operations.
I have been stuck at this issue for the whole day, I really hope some friends can help me out.
Thank you very much in advance.
I've had like the same issue. While updating the firmware it threw me that message and I could not reach my Gadgeteer *Fez Hydra at all. I managed to solve it by attaching an external power supply to it. I use the USB Client DP (Dual Power) 1.3. This way you do need the power over USB part and you can safely update the firmware.
USB Client: https://www.ghielectronics.com/catalog/product/280
edit: If that doesn't solve your isse you might want to reset the Loader first. Which is given as a tip on the GHI website before updating the firmware.
I'm getting an error: "all cuda devices are used for display and cannot be used while debugging"
(Using Ubuntu)
Is there ANY way to use Nsight eclipse with only one GPU for debugging?
I have seen solutions like
"sudo service lightdm stop"
to kill X but that kills Nsight eclipse too so what's the point?
Update: Since it is not possible to debug with the same GPU that runs X, I have to ask: How does one go about using ANOTHER computer in his home network to "remotely" access Ubuntu in such a way that the X desktop rendering will be performed by the Guest computer while letting the host GPU run the debugger?
In general, it's not supported to debug on the same GPU that is hosting an X display. From the nsight getting started guide: "A GPU that is running X11 (on Linux) or Aqua (on Mac) cannot be used to debug a CUDA application and will be hidden from the application ran in the debugger. Such GPU can still be used for profiling GPU applications. "
I believe there is actually different behavior amongst different window managers, however. I have a laptop with Quadro1000M and RHEL 6.2 (with GNOME), with CUDA 5.0, and I am able to get into the debugger in nsight EE (Project...Build Project followed by Run...Debug). At that point I can step through and set breakpoints in host code. And if I run the code to completion I get proper output. However, you still can't debug device code. If you set a breakpoint in the device code (and hit that breakpoint), you will hang the X session.
EDIT: CUDA 5.5 and beyond now support the ability to debug on a single cc3.5 or higher GPU.
It seems that you can use CUDA 5.5 to debug CUDA programs in a machine with only one GPU.
See section 1.7.3.2. CUDA-GDB of CUDA_Toolkit_Release_Notes
Another approach which might work is to use the onboard video output for the display.
That way you use the onboard graphics for the display and the GPU for debugging.
For this you have to:
Go to BIOS and change the primary display adapter to "On-Board" (this varies from manufacturer to manufacturer)
Physically connect you display to the on-board display output feed
Restart and then run Nsight
If you are using a system with no on-board graphics, then you are out of luck!
This guy here has been able to get it up and running in Windows with Visual studio and Nsight plugin.
P.S. You would probably need to edit your xorg.conf to make X use onboard graphics instead of your Nvidia GPU.