The program builds fine, but when I tried to flash code from snap debugger to PIC16F15313 in MPLAB its giving this error. Even though low voltage programming is enabled in code.
"MPLAB has detected that the low voltage configuration bit on the device is off. Because Snap can use only low voltage programming, this configuration bit must be turned on in order to use Snap. You will need to use a different, blank device, or use another debug tool to erase this device, before continuing with Snap.
Connection Failed."
I had same issue. My problem was in the wiring of debugger (one wire was not connected). I think that your problem may be similar. LVP should be set in new device by manufacturer.
Two issues:
Switch on low voltage programming:
#pragma LVP = ON
check the wiring:
Note: The MPLAB Snap In-Circuit Debugger is powered through its Micro-B USB connector. The target board must be powered from its own power supply. The debugger sense the target voltage.
Related
I have an AOSP tree compiled on my board. I bought a wireless keyboard and connected it to my board via usb port. I expect when the board is in the suspend state, it will wakeup by pressing a key on keyboard. But it is not so.
I tried several ways in my bootloader (uboot), kernel, etc. But no effect. Additionally I made an experiment and found out that in the sleep state, my usb port (which has a dongle in it) has just 1-5 mA. But it should be higher for the dongle to work!
Has anyone experienced this? How to enable remote wakeup for usb in android?
Thanks
More info:
The uboot supports usb host controller interface. I tweaked kernel build options. but these two actions has no effect.
EDIT : I work on p212 reference board of amlogic. Its SoC is Amlogic S905X.
EDIT 2 : I tested the board (which is a tv box actually) using my phone and its charger and I found that when the box goes to sleep, the charging is stopped!! So I can deduce that the dongle has not enough power to stay alive! (yet to send wake signal to SoC !)
Then I carried out a second experiment: I connected the phone using a USB charger which only has two pin instead of four. (Just voltage supply; differential pins (signal pins) are disconnected). The result: my phone is charging now!! It seems when the SoC is suspending, it sends a signal to USB peripherals telling them to not draw power. Am I correct? How can I configure my AOSP tree and Linux kernel and uboot bootloader to avoid happening this?
Please guide me how to fix it in kernel or other parts of stack!
EDIT 3 :
I have pasted my kernel config here. I configured these options to y but has no effect:
CONFIG_PM_RUNTIME=y
CONFIG_PM_AUTOSLEEP=y
CONFIG_PM_DEBUG=y
CONFIG_USB_OTG_WAKELOCK=y
CONFIG_USB_DEBUG=y
CONFIG_USB_OTG=y
Also this link is my device tree files. (in kernel. NOT uboot)
We programmed a STM32L072, using, for the lower layers, the HAL lib generated from cubeMX.
Note that the "programming style" in my enterprise does not involve to include a watchdog in their embedded devices. No comment.
During one particular field test (out of many), the device stopped working (i.e.: screen freeze, and no response on the communication bus, but the PWM driver was working).
The device has been restarted and after a few minutes of work, the freeze happened again. This happened a few times before we arrived.
We plugged a JTAG/ST-LinkV2, and nothing changed on bus or screen.
As soon as we unplugged the flasher, the device restarted working without a reset (we could have recognized a initialization pattern if it had happened).
I don't understand how JTAG specification could explain this behavior (i.e. the unfreezing)?
By the way, what can cause a freeze that can be unfrozen by a JTAG unplugging? Oscillator stopped? Auto sleeping modes? hardware breakpoint? software breakpoint? Interrupts disabled?
EDIT - Answer to comments and recap :
Not an oscillator cause because PWM is still working.
Software breakpoint? unlikely as none has been set before flashing the
program.
Concerning interrupts, I think this is an interesting lead, but how can the JTAG change anything by unplugging it?
Hard to determine without knowing more about your software. If the PWM is running, clearly the oscillator has not stopped. It sounds like the code may have an embedded software breakpoint instruction. The on-chip debug does not by default stop peripheral clocks when it hits a break-point.
Such instructions should be guarded to only block when the host debugger is attached (i.e. the debugger software, not just the physical JTAG hardware), e.g:
if (CoreDebug->DHCSR & 1) __BKPT(0);
If the breakpoint is not conditional on the debugger, the processor will halt with nothing to restart it (other than a watchdog, preferably the independent watchdog, because the windowed watchdog can be configured to have its clock stopped when a breakpoint is hit).
When a debugger is detached the break-point will be released, which may be what is happening here.
I'm having trouble with an industrial Linux computer I'm working with to achieve communication over an RS485 bus with multiple connected devices. What I've encountered is that the IO pins used by the RS485 USART driver are set to different levels at startup instead of going to the RS485 idle/tri-state. As a result, the other devices on the bus are blocked for more than 30 seconds while the device boots up, triggering all sorts of external problems. The course of events can be viewed in the attached image, where I've measured the output voltages with an oscilloscope during startup.
My guess is that the actual driver is not started until the voltage levels reach their tri-state levels (e.g. ~2.2V for this device). After that everything works as expected.
I've tried to find any config-files to set the default IO level of the pins at boot (thinking this may be set by the bootloader) to no avail.
Also, I've tried to apply a startup-script to run "early enough" to set DATA- high, but the device in question does not provide any interface to control these pins as regular GPIOs as far as I can tell.
Any help, tips or insights would be much appreciated!
EDIT: I am not an experienced Linux developer, so please highlight if I've left out any important details.
Some specs:
ARM920T rev 0 (v41) CPU
Proprietary distribution of Linux 2.6
Uses Busybox
Atmel USART drivers
Extract from boot log:
Linux version 2.6.28.10 (root#) (gcc version 4.1.2) #94 PREEMPT Tue Oct 29 10:22:19 CET 2013
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0003177
/...
.../
RS485 mode for port /dev/ttyS3 enabled
/...
... (I'm guessing the ~30 secs elapse here)
.../
atmel_usart.3: ttyS3 at MMIO 0xfffcc000 (irq = 9) is a ATMEL_SERIAL
atmel_serial.3: Putting the RS485 RTS pin down
/...
...
.../
Full boot log: https://drive.google.com/file/d/0B2XYl1mNCa8jNUZ5V0Nic1hkU0U/view
Similar issue:
Possibly a similar issue is discussed here: UART initialisation: Prevent UART to pull RTS high
But I'm not sure how to proceed with the suggested solution.
This is little more than wild speculation, but it might be worth adding a start-up script that echoes a NULL character to the device (e.g. /dev/ttyS1 or whatever) as early as possible during start-up. This might be enough to kick the driver into initialising the hardware.
You could also try to locate the driver in the Linux source to look at how it starts up.
Probably you have access to the source code, so you can investigate who and when mess with the that GPIO. Just grep the kernel source for the atmel gpio controller port addresses to figure out what happen. If you are lucky may be there will be kernel command line option that you can pass from the bootloader to set the line to what you need in advance.
this answer may work if you can find required things mentioned below
of your board!
Once I also had a same issue on PWM. There I found that my bootloader was responsible for the same, I changed in bootloader configuration and it started working fine.
Check your BSP provided by board vendor or third party (If you have the source), If your bootloader is U-boot you can find it inside U-boot-(source)/include/configs/(your-board).h there you can find configuration for RS484. As per your datasheet for the board you can check for other things which are muxed on the same pin and disable those if not required for boot time and enable RS485.
enabling/disabling can be done by changing the values 0, 1 or 2 as per your configuration and also you can simply disable anything just by commenting // out the line.
I am trying to export a pin (no. 110) using the following in linux:
echo 110 > /sys/class/gpio/export
When I try to do so, I getthe error message
ash: write error: Device or resource busy
As per my knowledge the pin is not being used by any module, but I may be wrong. I had the hardware line probed and the voltage is changing, the processor seems to be driving something to the line.
The pin according to the user manual is not multiplexed and is "commonly available".
The pin according to the user manual is not multiplexed and is "commonly available".
Apparently you are referring to a SoC manual.
Such a statement will only imply that the pin does not have a dedicated application by an integrated peripheral (as shipped by the SoC manufacturer).
That statement is invalidated when the SoC is designed into a circuit and/or installed on a board.
The document that you really need to consult is the board manual or the board schematics.
That should be the accurate documentation as to how the board designer used the available GPIO pins in that specific application.
When I try to do so, I getthe error message ...
Fortunately for you, the device driver that does use that pin (that you want to use) has properly performed the GPIO reserve/request call to prevent a hijack.
This prevented that other driver from breaking and/or a device/board malfunction.
As per my knowledge the pin is not being used by any module, but I may be wrong
How did you attain this "knowledge"?
Did you scan the .dts and .dtsi files used for your board?
Did you check the source code of every device driver used by your board?
I am working with Sasebo GII board that has two FPGAs on it:
Xilinx Spartan and Xilinx Virtex5 (and the board has several separate JTAG interfaces for configuration of fpgas).
I am useing ISE 14.4 under Linux and I have some troubles to configure the Virtex 5 FPGA.
(no problems with Spartan).
I am using "Impact" to send the configuration files to FPGAs.
At the beginning Impact scans the board and finds Spartan FPGA without problems
and I can configure it, but when I plug the cable to the other interface and press scan on Impact it says:
"There are many unknown devices being detected. Press Yes to continue or press No to stop."
If I press the NO option, well, obviously nothing happens :-)
And if I click on YES it fails, I can manually add Virtex5 FPGA, but than it fails to upload the config file to it (and even fails when I try to detect the device ID).
I already tried all JTAG interfaces on the board, nothing.
Same operations work on the same board with SPARTAN FPGA, so I'm stuck. Any ideas ?
Well, I am not familiar with that particular board, but there are many things you can look into when it comes to your JTAG problem.
Check the voltage of your VCC, make sure it has a good value for the board
Make sure your ground connection is well connected and you don't have much impedance
between the connector's GND and the boards GND
Try other JTAG connectors and see if you see any difference in the detection of the
devices.
Try to run the IMPACT in debug mode. Capture the data and see if the patterns look OK
Also something that may not be JTAG related, is to make sure your V5 device has all the powers it needs, if there are any power problems, it may cause the JTAG interface to behave like you explained here.
Also, look on the board and see if there are any switches or jumpers to chose different way of configuring the V5 device. This can be a big issues with multi-FPGA board, maybe the V5 is configured to be programmed from a controller or other devices on the board and the JTAG chain is not set up for programming.
These are just different thoughts, they may help you toward the right direction.
Found this on their site:
User guide for the board
To reprogram the flash ROM (ST45DB16D, U11) for the control FPGA (Spartan-3A), attach the configuration
cable to CN7. For configuration, use the provided mcs file sasebo_gii_ctrl.mcs.
Reprogram the flash ROM (ST45DB16D, U4) for the cryptographic FPGA (Virtex-5 LX30) with the provided
mcs file sasebo_aes_comp_lx30.mcs as well. Connect the configuration cable to CN4.
To configure the FPGA immediately after reprog
ramming of the flash ROM, cycle the power.
Blockquote
This means you can't program the FPGA directly, you need to convert your bit file into MCS file and then load it into the FLASH memory on the board.