In other words at what point do they overflow and reset to zero. The iptables manual appears not to say. Are they 32bit of 64bit?
See the man page:
The counters are 64-bit and are thus not expected to overflow ;)
Related
I have a Micro bit v1. Days before, I was unable to search the Bluetooth signal of it, so I followed the instruction on microbit.org to upgrade its firmware. But after I copied the firmware file into it, a FAIL.TXT file showed up in the disk MAINTENANCE. What's more, since then on, every time I connect the Micro bit to my computer, it enters this MAINTENANCE disk, no matter I press the Reset or not during the connection. I've tried different versions of firmwares of the Micro bit v1, but none of them succeed.
The details about this Micro bit are shown as below.
# DAPLink Firmware - see https://mbed.com/daplink
Unique ID: 00000000066aff565357825187123855a5a5a5a597969908
HIC ID: 97969908
Auto Reset: 0
Automation allowed: 1
Overflow detection: 0
Daplink Mode: Bootloader
Bootloader Version: 0254
Git SHA: db711ec68a861b9d9b0d7a7a82071796ec117687
Local Mods: 1
USB Interfaces: MSD
Bootloader CRC: 0x0697f838
Interface CRC: 0x4915d882
Remount count: 1
URL: https://mbed.com/daplink
The contents of FAIL.TXT are shown as below.
error: In application programming aborted due to an out of bounds address.
type: interface
So, I am wondering that, what possibly has occured this upgrade failure ? And how can I fix my Micro bit ?
I am 7 months late, I know, and I made an account just ot answer here. I see some strange things I haven't seen before in your details;
You're missing the part of the UID that specifies the version of the
Micro:Bit (4 first numbers are supposed to be 9900 for 1.3 and 9901
for 1.5, not sure if it's different if you have 1.0).
Interface version is missing from the details.
Local mods being set to 1 means you have unsaved local changes to the Micro:Bit.
Remount count being set to 1 means it has failed to flash the previous hex you tried to flash to it. Not a good sign, but it means you only tried (or it only counted) once to reflash the firmware.
Try flashing an erase hex to the Micro:Bit, then an up-to-date firmware hex, and lastly the OOB hex. This worked for me when I experienced a similar issue.
I hope any of this can help you, or any others that stumble upon this post in the future.
Please reach out if you still need help!
This micro:bit has wrong HIC ID (97969908 instead of 97969901). It doesn't have original bootloader that's why you are not able to flash original interface firmware. According to DAPLink 97969908 is STM32F103XB bootloader. I think there are 2 possible solutions: 1st is to flash original bootloader and original interface firmware then, 2nd is to make some with DAPLink source files to compile a new interface firmware that would work with 97969908 bootloader.
See here https://github.com/ARMmbed/DAPLink/discussions/956
I am porting the USB driver from the STM32F4 device to STM32L4 device. It almost works. During the enumeration it sends and receives the information, but the data is not exactly the same as from the "plain" STM Cube generated project. II have the same settings in both project but get the strange results.
I lost a week trying to find the solution, maybe someone here had a similar problem and can help me out. Sorry for the images but there is no other of posting some informations on the SO
As you can see the packets are almost the same, but not identical. After 25th transmition the board stalls and accepts only very limited number of the requests
The both files form the wireshark (in the wireshark and text formats) are here:
https://gitlab.com/diymat/usb-problem/tree/master
The ep* files are form my port, stmcdc* - STM Cube generated one. Both were running using the same hardware.
Is it same clock config ?
Is 48MHz USb clk ok ?
Using non crystal or ext osc to get 48MHz USB commonly lead to issue on large xfer Even on F4 can't say for l4
So it may appear to work with hid and rather short packet but start mis-behaving for larger xfer
So I would like to be of a bit better help, but I would definitely need more information to give you a good direction to head in. That being said, there could be a number of things wrong, so I will try to cover what I can think of. Let's start with some of the most obvious.
Clock configuration/hardware can be causing problems due to faulty components, or incorrect selection of software/hardware. This can cause a number of issues, but this could be a symptom of that.
If you are using the generated FATFS middleware from ST, Small stack size inside of the configuration of the L4 can cause this exact problem. it may work until the PC register receives an erroneous error which could lead to some sort of fault, or in some cases, just a bad result returned inside of the FATFS, or USB peripheral code from ST and it will return a dirty sector on the USB window read from the FATFS, which will result in terminated operations on the peripheral.
I see you're using STM32Cube, so you can edit stack and heap size by opening the file startup_stm32l475xx.s
and edit the two as you see fit for your application.
; Amount of memory (in bytes) allocated for Stack
; Tailor this value to your application needs
; <h> Stack Configuration
; <o> Stack Size (in Bytes) <0x0-0xFFFFFFFF:8>
; </h>
Stack_Size EQU 0x400
AREA STACK, NOINIT, READWRITE, ALIGN=3
Stack_Mem SPACE Stack_Size
__initial_sp
; <h> Heap Configuration
; <o> Heap Size (in Bytes) <0x0-0xFFFFFFFF:8>
; </h>
Heap_Size EQU 0x200
Try increasing the stack size and see what happens. Good luck on finding your solution!
The N210 is connected to the RF frontend, which gets configured using the GNU Radio Companion.
I can see the signal with the FFT plot; I need the received signal (usrp2 output) as digital numbers.The usrp_sense_spectrum.py output the power and noise_floor as digital numbers as well.
I would appreciate any help from your side.
Answer from the USRP/GNU Radio mailing lists:
Dear Abs,
you've asked this question on discuss-gnuradio and already got two
answers. In case you've missed those, and to avoid that people tell
you what you already know:
Sylvain wrote that, due to a large number of factors contributing to
what you see as digital amplitude, you will need to calibrate
yourself, using exactly the system you want to use to measure power:
You mean you want the signal power as a dBm value ?
Just won't happen ... Too many things in the chain, you'd have to
calibrate it for a specific freq / board / gain / temp / phase of the
moon / ...
And I explained that if you have a mathematical representation of how
your estimator works, you might be able to write a custom estimator
block for both of your values of interest:
>
I assume you already have definite formulas that define the estimator for these two numbers.
Unless you can directly "click together" that estimator in GRC, you will most likely have to implement it.
In many cases, doing this in Python is rather easy (especially if you come from a python or matlab background),
so I'd recommend reading at least the first 3 chapters of
https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
If these answers didn't help you out, I think it would be wise to
explain what these answers are lacking, instead of just re-posting the
same question.
Best regards, Marcus
I suggest that you write a python application and stream raw UDP bytes from the USRP block. Simply add a UDP Sink block and connect it to the output of the UDH: USRP Source block. Select an appropriate port and stream to 127.0.0.1 (localhost)
Now in your python application open a listening UDP socket on the same port and receive the data. Each sample from the UDH: USRP Source is a complex pair of single prevision floats. This means 8 bytes per sample. The I float is first, followed by the Q float.
Note that the you need to pay special attention to the Payload Size field in the UDP Sink. Since you are streaming localhost, you can use a very large value here. I suggest you use something like 1024*8 here. This means that each packet will contain 1024 IQ Pairs.
I suggest you first connect a Signal Source and just pipe a sin() wave over the UDP socket into your Python or C application. This will allow you to verify that you are getting the float bytes correct. Make sure to check for glitches due to overflowing buffers. (this will be your biggest problem).
Please comment or update your post if you have further questions.
I want to send my encoded NAL packets via UDP as a fast webcam streaming program.
Because of the MTU size, I want to set the NAL packets to a max size of around 1390 bytes.
I've found another response on Stack Overflow explaining that one has to set the i_max_slice_size or something, but this was for x264. I've been trying to find the equivalent for x265 but I cannot see it anywhere.
I am using the libx265 (using x265.h) library for encoding.
Can anyone guide me in the right direction please? All help is greatly appreciated!
AFAIK there is no such thing in libx265 currently (it is in earlier stage of development and not all use cases are currently covered). Also as far as I looked it doesn't support more than one slice per frame at all currently not saying about size limited slices.
I just got my BeagleBoard-Xm and I'm wondering if there is any detailed step by step tutorials on how to get a very simple bare metal software running on the hardware?
The reason I ask is I want to deeply understand how the hardware architecture works, everything from the bootloader, linkers, interrupts, exceptions, MMU etc. I figured the best way is to get a simple hello world program to execute on the beagleboard xm without an OS. Nothing advanced, just start up the board and get a "hello world" output on the screen. thats it!
The next step would be getting an tiny OS to run, that can schedule some very simple tasks. No filesystem needed, just to understand the basics of the OS.
Absolutely no problem...
First off get the serial port up and running, I have one of the older/earlier beagleboards and remember the serial port and just about everything about the I/O being painful, nevertheless get a serial port on it so you can see it boot.
It boots uboot I think and you can press a key or esc or something like that to interrupt the normal boot (into linux). From the uboot prompt it is easy to load your first simple programs.
I have some beagleboard code handy at the moment but dont have my beagleboard itself handy to try them. So go to http://sam7stuff.blogspot.com/ to get an idea of how to mix some startup assembler and C code for OSless embedded programs (for arm, I have a number of examples out there for other thumb/cortex-m3 platforms, but those boot a little differently).
The sam7 ports for things and memory address space is totally different from the beagleboard/omap. The above is a framework that you can change or re-invent.
You will need the OMAP 35x techincal reference manual from ti.com. Search for the omap part on their site OMAP3530.
Also the beagleboard documentation. For example this statement:
A single RS232 port is provided on the BeagleBoard and provides access to the TX and
RX lines of UART3
So in the trm for the omap searching for UART3 shows that it is at a base address of 0x49020000. (often it is very difficult to figure out the entire address for something as the manuals usually have part of the memory map here, and another part there, and near the register descriptions only the lower few bits of the address are called out.)
Looking at the uart registers THR_REG is where you write bytes to be sent out the uart, note that it is a 16 bit register.
Knowing this we can make the first program:
.globl _start
_start:
ldr r0,=0x49020000
mov r1,#0x55
strh r1,[r0]
strh r1,[r0]
strh r1,[r0]
strh r1,[r0]
strh r1,[r0]
hang: b hang
Here is a makefile for it:
ARMGNU = arm-none-linux-gnueabi
AOPS = --warn --fatal-warnings
COPS = -Wall -Werror -O2 -nostdlib -nostartfiles -ffreestanding
uarttest.bin : uarttest.s
$(ARMGNU)-as $(AOPS) uarttest.s -o uarttest.o
$(ARMGNU)-ld -T rammap uarttest.o -o uarttest.elf
$(ARMGNU)-objdump -D uarttest.elf > uarttest.list
$(ARMGNU)-objcopy uarttest.elf -O srec uarttest.srec
$(ARMGNU)-objcopy uarttest.elf -O binary uarttest.bin
And the linker script that is used:
/* rammap */
MEMORY
{
ram : ORIGIN = 0x80300000, LENGTH = 0x10000
}
SECTIONS
{
.text : { *(.text*) } > ram
}
Note the linux version from codesourcery is called out, you do not need that version of a gnu cross compiler, in fact this code being asm only needs an assembler and linker (binutils stuff). The arm-none-eabi-... type cross compiler will work as well (assuming you get the lite tools from codesourcery).
Once you have a .bin file look at the help on uboot, I dont remember the exact command but it is probably an l 0x80300000 or load_xmodem or some such thing. Basically you want to x, or y or z modem the .bin file over the serial port into memory space for the processor, then using a go or whatever the command is tell uboot to branch to your program.
You should see a handful of U characters (0x55 is 'U') come out the serial port when run.
Your main goal up front is to get a simple serial port routine up so you can print stuff out to debug and otherwise see what your programs are doing. Later you can get into graphics, etc. but first use the serial port.
There was some cheating going on. Since uboot came up and initialized the serial port we didnt have to, just shove bytes into the thr. but quickly you will overflow the thr's storage and lose bytes, so you then need to read the trm for the omap and find some sort of bit that indicates the transmitter is empty, it has transmitted everything, then create a uart_send type function that polls for transmitter empty then sends the one byte out.
also forget about printf(), you need to create your own print a number (octal or hex are the easiest) and perhaps print string. I do this sort of work all day and all night and 99% of the time all I use is a small routine that prints 32 bit hex numbers out the uart. from the numbers I can debug and see the status of the programs.
So take the sam7 model or something like it (note the compiler and linker command line options are important as is the order of files on the link command line, the first file has to be your entry point if you want to have the first instruction/word in the .bin file be your entry point, which is usually a good idea as down the road you want to know how to control this for booting from a rom).
You can probably do quite a bit without removing or replacing uboot, if you start to look at the linux based boot commands for uboot you will see that it is copying what is pretty much a .bin file from flash or somewhere into a spot in ram, then branching to it. Now branching to linux, esp arm linux involves some arm tables and possible setting up some registers, where your programs wont want or need that. basically whatever command you figure out to use, after you have copied your program to ram, is what you will script in a boot script for uboot should you choose to have the board boot and run like it does with linux.
Saying that you can use jtag and not rely on uboot to work, when you go that path though there are likely a certain number of things you have to do on boot to get the chip up and running, in particular configuring the uart is likely a few clock dividers somewhere, clock enables, I/O enables, various things like that. Which is why the sam7 example starts with a blink the led thing instead of a uart thing. The amotek jtag-tiny is a good jtag wiggler, I have been quite pleased, use these all day long every day at work. The beagleboard probably uses a TI pinout and not the standard ARM pinout so you will likely need to change the cabling. And I dont know if the OMAP gives you direct access to the arm tap controller or if you have to do something ti specific. You are better off just going the uboot route for the time being.
Once you have a framework where you have a small amount of asm to setup the stack and branch to your entrypoint C code, you can start to turn that C code into an OS or do whatever you want. If you look at chibios or prex or others like it you will find they have small asm boot code that gets them into their system. Likewise there are uart debug and non-debug routines in there. Many rtoses are going to want to use interrupts and not poll for thr to be empty.
If this post doesnt get you up and running with your hello world (letting you do some of the work), let me know and i will dig out my beagleboard and create a complete example. My board doesnt exactly match yours but as far as hello world goes it should be close enough.
You could also try TI StarterWare:
http://www.ti.com/tool/starterware-sitara