I have an ATXMEGAA3BU processor and I use a CrossPack on my MacOS. I would like to use my old USBASP pragrammer which is "configured" to programm the CPU through the PDI interface - that is not a problem.
The problem is that I do not know how to setup the FUSES on this ATXmega.
For ordinary CPU like ATMega8 the sequence in the Make file was simple.Just use this: FUSES = -U hfuse:w:0xd9:m -U lfuse:w:0x24:m
But the Xmega has five FUSEBYTES and I have a problem with them... so the simple question is "how to change e.g. JTAGEN from 0 to 1"? It is located in teh FUSEBYTE4 as bit 0. How to tell the CrossPack (avr-dude) to change this or other from e.g. FUSEBYTE0?
Thank you...
Maybe this is related to Robotics StackExchange.
But I will try to answer here.
If it's possible for you to switch to windows, The fuse bit changing progress is very easily done with CodevisionAVR. With just some single clicks it's done. and it doesn't have the headaches of this terminal commands.
Please refer to the datasheet for xmega a3bu at : http://www.atmel.com/Images/Atmel-8331-8-and-16-bit-AVR-Microcontroller-XMEGA-AU_Manual.pdf
The name of the fuse bytes are: FUSEBYTE0, FUSEBYTE1, ... FUSEBYTE5. There's no FUSEBYTE3. Have you tried
-U fusebyte0:w:0xd9:m -U fusebyte1:w:0x24:m -U fusebyte2:w:0x24:m and so on. You could give it a shot with exercise precaution while calculating the fuse bits and the lock bits.
I know this is probably too late for OP, but for others (like me) who come across this question, you can also add
FUSES =
{
0x00,//sets jtag address
0xAA,//fuse byte 1
0x9D,//f byte 2
0x00,//unused
0xDE,//f byte 4
0x1E //f byte 5
};
to the top of your main.c file and the compiler / programmer will take care of flashing them.
Tested on xmegaA4.
Related
Currently I am reading the MDB_interface_specification( (https://namanow.org/wp-content/uploads/Multi-Drop-Bus-and-Internal-Communication-Protocol.pdf) Version 4. 3(July 2019). In Kapitel 2.3 page 34 they are talking about the Peripheral Address and I don't undrstand how the Address scheme has been built . One prototy of the address scheme look like this: 00101xxxB ( this can be 28H for example ). They upper five bits are used for addressing and the lower 3 bit are the command. If i considered this statement wih my example then the address ist 5 and the Command is 0. I am a little bit confuse can someone please explain me that?
OK. First, read this:
Then, we have value 0x00 as command to Energy Management System (huh, i never saw this kind of MBD device in the wild). MDB datasheet doesn't contain any references to this device yet, but seems it's just POLL command, device must respond to POLL with last status changes (if any) or just ACK with x100 - it's not mistake, it's 0x00 with 9th bit set. Don't read this datasheet unless you want to lose your mind. I am already read this awesome shit and put it (mostly) to hardware implementation see github repo with complete solution
Cheers.
I'm currently tuning some code written for an STM32F070, where we use one byte on user option byte to keep some flags between Resets, using:
FLASH_ProgramOptionByteData(ADRESSE_OPTION_BYTE_DATA0, status_to_store);
Reading carefully the datasheet from our new STM32F446 lets me think that it is no longer possible to use option bytes to store one user byte...
1 - Am I Right with this assertion ? If not, what did I miss ?
2 - Is there some workaround, not involving to rewrite a sector of the flash ?
I am not an expert on stm32, rather still a beginner, but maybe you could have a look on the RTC backup register to hold your data ?
I have been working with ATmega128 and other such series for about 2 years and used a UART library for serial transmission. I am pretty sure the library is correct because I have used it hundreds of times but from the past few months I cannot do UART on my ATmega128. I am sure that my hardware is correct, I am sure of my code and to add to it, the same hex file runs good in other two ATmega boards but not in other boards.
PORTs are giving 5V output when all pins coded to give output.
Statements execute before any UART function occurs and after that it stops (does nothing, no UART, not even statements after UART)
I tried copy pasting UART code completely in main.c and it worked then.
Please help! I have no idea what is going on.
Well, after a lot of tussle, I finally found the problem and solved it. When I checked the fuse bits of the other microcontroller (the working one), I found Extended Fuse bits different from the not working microcontroller. I changed the Extended Fuse bits to 0xFF and problem solved.
Currently I'm trying to check the booting time of an Tixi board using systemd on a 2.6.39 linux kernel. To do so I created a service file that calls a bash script which sets and uses a gpio. The problem is that my systems is not allowing me to change the value of the gpio. I can sucessfully export it, change its direction, but NOT the value. I have connected an oscilloscope to check if the value had changed in the hardware but not updated in the file as suggested in some forums, but it was the same: the value just doesn't change!
I should also point out that the same script is working if I use system V, with exactly the same coonfiguration for the kernel, busybox and filesystem.
It is very ironic because I'm already the root of the systems, nevertheless even changing the permissions of the file, would not allow me to change its value. There is also no feedback from the kernel saying that the operation was not possible, but rather it looks as if it was possible but when I check the value, it was the same as before.
I also tried to run that in the Raspbian with a 3.12 (which I changed to systemd) and it was in fact possible to do it, just in the normal way from userspace.
I would appreciate if you have any idea oh what might be the problem since I already run out of ideas.
Thanks
PS: This is the code that should work on the bash line:
echo 0 > /sys/class/gpio/gpio104/value
more /sys/class/gpio/gpio104/value
// I get 1 not 0 as I requested
Nevertheless the same lines of code in the same board work if I use systemV but not if I use systemd
Probably cause by the lack of udev in your new setup which change the permission for those gpio in /sys/class. You might want to just put back udev to see if it fixes your problem.
I don't know your image setting, but each gpio pins needs to be exported prior to usage. Are you doing it or it's done automatically? If you have omap mux kernel switch, you do something like :
echo 0x104 > /sys/kernel/debug/omap_mux/cam_d5 (set mode 4 as stipulate in TI Sitara TRM)
echo 104 > /sys/class/gpio/export (export the pin)
echo out > /sys/class/gpio/gpio104/direction (set the pin as output)
Also do a dmesg | grep gpio and see if there's any initializing problem with the gpio mux.
Actually I've faced an issue similar to your's , ie was not able to change the value of set of gpio pin manually
Finally the result obtained was even though the name of that pin is gpio it can only be used for input only (DM3730 gpiO_114 and gpio_115).
So please refer to the datasheet and confirm it can be used for I/O operations..
I am trying to use the expansion header to control a couple motors and auxiliary task mechanism. For this I am using the appropriate pins as GPIO and merely attempting to send high or low signals as needed by the robot. (For instance, I might need the robot to move forward and so I'd send high signals on both sets of pins, whereas if I needed the robot to turn I'd send a high signal to one pin and a low to the other.)
However, the problem is that the pins will only stay high! I've followed the conventions for sysfs just via the terminal, and, although I'm able to set the "values", "active_lows", etc. to 0 or 1, I can't actually get the pins to send 0V. After checking the beagle.h file I used for u-boot it looks like the multiplexer mode is configured correctly. This is also reflected when I get the info from sys/class/gpio/gpio%/% and sys/kernel/debug/gpio. Furthermore I don't get any errors or indication from anywhere that there is something wrong...it just doesn't work!
What should I do? For the first time in my life I have seemingly exhausted the internet...
details:
Beagleboard xm rev c1
ubuntu 12.04
kernel 3.6.8-x4
Im pretty new to the beagle board and I have recently been trying to configure the GPIO pins on my classic beagleboard c4, which i believe should be fairly similar.
Half of my GPIO pins seemed to work fine and the other half seemed to remain high or low no matter what i did. Even though they were configured the same way as the working pins in /sys/class/gpio/
have you tried to use other gpio pins?
I ended up following http://labs.isee.biz/index.php/Mux_instructions
to configure the mux to 4 and now i can control the pins that were not working.
I basically used the command:
sudo echo 0x004 > /sys/kernel/debug/omap_mux/(mux 0 name)
where (mux 0 name) was the name of the subsystem for the mux 0 setting for the gpio pin you wish to configure
ie. for gpio 183 on beagleboard c4
sudo echo 0x004 > /sys/kernel/debug/omap_mux/i2c2_sda
Though I had to change permissions to modify these files
As I said I am pretty new to the beagleboard and ubuntu but this worked for me so I thought I would share it with you, I hope it is of some help.
Regards;
Paul;
It seems that the beagleboard expansion pins are numbered in alternating fashion, as clearly and professionally depicted here.
Thanks to everyone for your help. I now know way more than I should about GPIO on OMAP systems (and so do you). Good luck on finals/life!**
tl;dr I'm an idiot!