I created my own custom board and added a ICSP header, although I can't seem to program it.
My board has a Atmega32U4 (no external crystal) and I keep getting an error when I use the command:
avrdude -p m32u4 -c usbasp -B 64 -U flash:w:/Users/Jbonnett/Desktop/RGBWstrandtest.ino.hex
The error:
avrdude: set SCK frequency to 8000 Hz
avrdude: error: program enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
As you can see I am trying to program the chip in slow mode and I also tried the hardware jumper for slow mode. Although the error is telling me that it can't see my custom board.
The programmer that I am using is this one: https://www.ebay.co.uk/itm/USBASP-USB-ISP-Programmer-for-Atmel-AVR-ATMega328-ATMega32U4-Arduino/322662323277
Here are a couple of photos to show that the custom board is wired up correctly:
Please note that the programmer can be powered by the custom board.
Thanks for any help :)
Edit: My Schematic
With the limited information, there are many possibilities, you could check the following, though not a comprehensive list, should narrow it down:
(1) Try using the -F parameter to check if you can get a little further
(2) Check if the USBAsp works with a standard 32u4 board
(3) Check if the ISP header connections are correct, sometimes the labeling of the pins might be reversed due to any mistake in the schematic/layout/fab
(4) The Fuses on the 32u4 may be set to use external oscillator (though I have never seen this setting on factory 32u4, default is always internal RC), in which case we need an external crystal to program.
Ok so I added a crystal and it works! Even though it has an internal one I have no idea why it didn't work without one :(
Related
I am trying to manually set the ISER0 and STIR registrs to invoke interrupt number 3 which is RTC Wakeup Interrup for educational purposes. Here is my code:
I step through the register contents, but somehow the code was not able to write to the ISER0 and STIR registers, as is shown below where i am trying to clear the ISER0 register.
Can someone please explain me what am i doing wrong here?
ISER has one bit for every exception, STIR takes exception number - 16.
In the second image you write 0 to the ISER register. That has no effect as described from both ARM architecture reference manual and STM32 M4 Programming Manual.
I would put a volatile on both register pointers declaration, but in this case I don't think it's an issue.
The issue is solved. Somehow, the stlink debug with openOCD was causing an issue with semihosting enabled to which i have no explanation for now. When I changed the debugging to STLink with SWV viewer, it worked ok...
I'm getting comfortable with dotMemory CLT and I'd like to understand if/how I can enable the collection of allocation data with a command line flag.
With the API, I'm aware of the ability to leverage MemoryProfiler.EnableAllocations, and with the desktop application I simply check a box
But I find no references to this concept with respect to the CLT.
Attempting to use start doesn't do the trick, and poring over dotMemory help start doesn't reveal anything promising.
Is this simply not-supported, or am I missing/mis-understanding a critical section of documentation?
Line copied from dotMemory.exe help start |more
[--collect-alloc|-c] Collect callstack allocation data (impacts performance!)
Example: dotMemory start "C:\Path\To\YourProgram.exe" -c
I am using Vivado for running my Verilog codes. Even though I do not see any errors while running synthesis and implementation, bitstream cannot be built.
This is the error I get:
ERROR: [Drc 23-20] Rule violation (NSTD-1) Unspecified I/O Standard - 12 out of 12 logical ports use I/O standard (IOSTANDARD) value 'DEFAULT', instead of a user assigned specific value. This may cause I/O contention or incompatibility with the board power or connectivity affecting performance, signal integrity or in extreme cases cause damage to the device or the components to which it is connected.
Which also suggests:
To correct this violation, specify all I/O standards. This design will fail to generate a bitstream unless all logical ports have a user specified I/O standard value defined. To allow bitstream creation with unspecified I/O standard values (not recommended), use this command:
set_property SEVERITY {Warning} [get_drc_checks NSTD-1]
NOTE: When using the Vivado Runs infrastructure (e.g. launch_runs Tcl command), add this command to a .tcl file and add that file as a pre-hook for write_bitstream step for the implementation run.
Which comes down to how can I script in Tcl using Vivado? I added the suggested command to the tcl console but I still get the same error.
I sugest you do what the tool is telling to do, which is specify IO standard for your top level ports, for example, if you have sys_rst_n top level port you may add the following line to your .xdc constraint file:
set_property IOSTANDARD LVCMOS18 [get_ports sys_rst_n]
of course you should change LVCMOS18 to match IO standard of you port.
The error you get is really not a Tcl issue.
YOU WANT to fix these IOs, otherwise you may damage your hardware.
open the routed checkpoint (dcp)
using the IO port window fix the IOs that have default IO standard (one by one if needed)
create the bitstream from the tcl window
Here's how to create a .tcl to fix this without having to re-implement the whole project:
copy the commands that ran to fix the IOs from above (from the tcl console) and put the commands in a tcl file
add this tcl file as a hook to "post route physopt" so the tcl runs automatically when this last step in the implementation flow.
if you'll be rerunning implementation in the future, you should just place the commands in the project xdc file instead.
I want to develop a VGA graphics driver (for Linux(Ubuntu)) with support for the basic primitives such as putpixel, drawline, fillrect and bitblt. I want to do it in protected mode.
I´ve been googling for a week and the following four links are the best I have found:
http://www.brackeen....vga/basics.html
http://www.osdever.n...VGA/vga/vga.htm
http://bos.asmhacker...sing%20bios.htm
Unfortunately, the first one uses a BIOS call so I cannot use it. The second link has lots of information on the VGA registers but no examples showing how to make them work together. The third example is a example to switch in 13h mode but i've tried it and nothing happened. Can you guys give me a hint? Thanks in advance!
--Vincenzo
my code at http://bos.asmhackers.net/docs/vga_without_bios/snippet_5/vga.php
works fine if you are in 32bit mode with full hardware access. Unfortunately I doubt that any Linux variant will let you directly access the VGA ports. I'm not sure how you develop this driver, but if you made sure that you have full access to the VGA ports it should work. In my example code I only switch between mode 0x03 and 0x13, but in the folders above you'll be able to find port values for most other common VGA modes, as well as C code to do the switch if you prefer that.
Christoffer code include files are found BOS operating system source code like text.inc and font8x16.inc
http://bos.asmhackers.net/downloads.php
This is coming many many years later but I think it's still very relevant and if somebody is struggling I hope they can find it useful.
First of all, it is completely possible to configure VGA only using registers without interrupts, as hard as it may be. A useful resource about registers and how to configure them can be found here, but unless you have a ton of time to spare to learn how to properly do all of it, move to the following section.
If you wish to really learn how to do it, I suggest going through with the documentation provided earlier. However, some of it is already done!
Chris Giese did a great job demonstrating exactly how to do this for MS-DOS system, and while you may think that doesn't help you, it really does.
Chris's code can be found here. If you want another useful codes check here as well.
Now, while it only works for MS-DOS it's actually easy to convert to other systems. The code already contains all data needed to configure the registers in many different modes. And that's the part that saves you a ton of time going through documentation.
The code uses functions outportb, inportb, which are MS-DOS functions, to write/read single byte to/from a port. Therefore, you have to redefine these functions to read/write for your own system. Redefinition complexity depends on the system you operate on.
In addition, you will also need to provide means to write to physical memory region between 0xA0000-0xBFFFF which corresponds to standard VGA memory area. Once you have that allocated, you need to also redefine the functions pokeb pokew peekb which will help you output things (text or pixel data) on the screen.
One last note: the code is already defined to work with many different modes including both text and display modes.
Good news, my c64 ist still running after lots of years spending time on my attic..
But what I always wanted to know is:
How can I automatically load & run a program from a floppy disk that is already inserted
when I switch on the c64?
Some auto-running command like load "*",8,1 would be adequate...
Regards
MoC
You write that a command that you type in, like LOAD"*",8,1 would be adequate. Can I assume, then, that the only problem with that particular command is that it only loads, but doesn't automatically run, the program? If so, you have a number of solutions:
If it's a machine language program, then you should type LOAD"<FILENAME>",8,1: and then (without pressing <RETURN>) press <SHIFT>+<RUN/STOP>.
If it's a BASIC program, type LOAD"<FILENAME>",8: and then (without pressing <RETURN>) press <SHIFT>+<RUN/STOP>.
It is possible to write a BASIC program such that it automatically runs when you load it with LOAD"<FILENAME>",8,1. To do so, first add the following line to the beginning of your program:
0 POKE770,131:POKE771,164
Then issue the following commands to save the program:
PRINT"{CLR}":POKE770,113:POKE771,168:POKE43,0;POKE44,3:POKE157,0:SAVE"<FILENAME>",8
This is not possible without some custom cartridge.
One way to fix this would be getting the Retro Replay cartridge and hacking your own code for it.
I doubt there is a way to do it; you would need a cartridge which handles this case and I don't think one like that exists.
A better and more suitable solution is EasyFlash actually. Retro Replay is commonly used with its own ROM. Since it is a very useful cartridge by default ROM, I would never flash another ROM to it. Also it is more expensive than EasyFlash if you don't have any of those cartridges.
At the moment, I have Prince Of Persia (!) ROM written to my EasyFlash and when I open my c64, it autoruns just like you asked for.
Not 100% relevant, but C128 can autoboot disks in C128 mode. For example Ultima V (which has musics on C128 but not on C64 or C128 in C64 mode) autoboots.
As for cartridges, I'd recommend 1541 Ultimate 2. It can also run games from module rom images (although Prince of Persia doesn't work for me for some reason, perhaps software issue?), but you also get rather good floppy emulator (which also makes it easier to transfer stuff to real disks), REU, tape interface (if you order it) etc.
If you are working with a ML program, there are several methods. If you aren't worried about ever returning to normal READY prompt without a RESET, you can have a small loader that loads into the stack ($0100-$01FF) The loader would just load the next section of code, then jump to it. It would start at $0102 and needs to be as small as possible. Many times, the next piece to load is only 2 characters, so the file name can be placed at $0100 & $0101. Then all you need to do is set LFS, SETNAM, LOAD, then JMP to it. Fill the rest of the stack area with $01. It is also rather safe to only save $0100-$010d so that the entire program will fit on a single disk block.
One issue with this, is that it clears out past stack entries (so, your program will need to reset the stack pointer back to the top.) If your program tries to do a normal RTS out of itself, random things can occur. If you want to exit the program, you'll need to jmp to the reset vector ($FFFC by default,) to do so.