I'm using an NXP Kinetis K64 ARM Cortex M4 MCU. I successfully altered the linker configuration file to move my vector table to address 0x8000 (instead of the 0x0000 default). When I tell the CodeWarrior 10.6 debugger to break at the start of the code, it stops at the top of the boot.S file as expected. But it dawned on me, HOW did the MCU/debugger find the code since the flash memory is empty (0xFF) from address 0x0000 to 0x7FFF and the VTOR register shows as 0x0?!
I looked through the datasheets of both the ARM M4 core and the NXP K64, but they don't answer this scenario.
It is probably due to the settings of your Debug Configurations in CodeWarrior. In Debugger tab, if Initialized program counter at is ticked as shown below, the debugger will give Program Counter, at reset, the address of "the top of the boot.S file", which is the Program entry point. The normal sequence of finding the vector table is skipped.
Your program will not run without the debugger.
Further details about the CodeWarrior Debugger can be found here
Related
I have a custom board with an STM32WB55CEU (512K Flash) that is failing to start the BLE stack on CPU2 in the function SHCI_C2_BLE_Init(). I believe it's failing this function because it failed to load the BLE firmware (stm32wb5x_BLE_Stack_full_fw v1.13.0) correctly. Whenever I try to load the firmware I get an error at the end saying FUS_IMAGE_NOT_AUTHENTIC or FUS_STAE_IMG_NOT_AUTHENTIC depending on whether I try it from the command line over USB or through the GUI over SWD. I can delete the firmware image without error and my FUS appears to be up to date and running before I attempt the update.
Firmware Update Screen from STM32CubeProgrammer
Security Configuration Option bytes
I've also tried deleting the firmware by changing the RDP register from AA to BB and back. I still get the authentication error. This only happens on about half of the boards that I've loaded (13 out of 25). I feel like there is an address of setting somewhere that I'm not setting correctly and since all of the other posts I can find on this issue use the Nucleo with the 1MB flash part I'm not sure if my parts settings should be different. I am putting the FUS and BLE firmware at the correct address for my part according the v1.13 release notes.
Any help to get past this authentication issue would be appreciated. Thanks.
I'm developing a tool for Intel PIN. Somewhere in the runtime, it gives me the below error. I want to know if there is a way to tell PIN to print the backtrace or let me handle the segfault in the tool itself.
I'm running my tool with MPI and it crashes when I insert values into an unordered map.
C: Tool (or Pin) caused signal 11 at PC 0x2b09594533cb
mpirun -np 44 pin-3.7-97619-g0d0c92f4f-gcc-linux/pin -follow_execv -t pin-3.7-97619-g0d0c92f4f-gcc-linux/source/tools/Simp ... -- program
You can use the following API:
PIN_AddInternalExceptionHandler()
from where you get access to an EXCEPTION_INFO structure which is supposed to be manipulated with the exception API.
Otherwise, you can also debug your tool from within a debugger, by launching your tool with the -pause_tool 20 option. Then you have 20 seconds to attach your debugger to the process. Once attached, the debugger stops (at least with Visual Studio) and lets you set the breakpoints you need in your tool's code.
This is not that easy to debug though, as the whole system switch from pintool code, to pin, to target application constantly. Hence there is not a continuous process of steps inside your pintool code that you can follow, as you can expect when debugging "classic single threaded applications".
I'm making a heart rate analyze, but I'm having a real problem with that. When I'm press to start the programm doesn't work, so, I've press to stop the running program and it shows me in the section where it's ready to close or finish the connection:
Error 5002 occurred at Init.vi. Unable to establish connection with
Arduino. Please ensure that you have selected the correct COM port
and that you have flashed the Arduino with the correct firmware.
This error code is undefined. Undefined errors might occur for a
number of reasons. For example, no one has provided a description for
the code, or you might have wired a number that is not an error code
to the error code input.
Additionally, undefined error codes might occur because the error
relates to a third-party object, such as the operating system or
ActiveX. For these third-party errors, you might be able to obtain a
description of the error by searching the Web for the error code
(5002) or for its hexadecimal representation (0x0000138A).
This is my VI diagram:
And this is my control panel:
And the connections to my arduino:
So:
how can I solve this problem?
Where can I find more information to get this
Thanks for your help, but I'm new on this world (Arduino and Labview)
Follow the suggestion given in error message. First of all, make sure that you could communicate with Arduino using some simple serial line terminal, like RealTerm, or HTerm. In case if you couldn't send any command using serial line terminal, check out which firmware do you have on Arduino.
This is the way, how you could troubleshoot this issue...
You can ignore the second and third paragraphs of that error message; they're generated because the Arduino VI's you're using are generating a custom error code that they haven't registered with the LabVIEW development environment, so its automated error handling doesn't know what they mean. The information you need is in the first paragraph though.
As kosist's answer says, the first thing to check is that you can communicate with the Arduino at all. Before you even start with LabVIEW, have you tried using the Arduino IDE to program your device with a simple program like the 'blink' example?
If that works, then the next step is to make sure you've programmed your Arduino with the firmware it needs to communicate with the LabVIEW VIs you're using (can you link to where you got them from?) and then try a much simpler test program in LabVIEW - again, just get the Arduino to do something simple like turn the buzzer on and off. If you hit a problem with any of those, I suggest asking a new question with details of exactly what you tried and what errors you saw.
On my raspberry pi running raspbian (unix based i think) I get this error "job pending on /dev/sda1" every time that i plug in my USB flash drive. from my research it has something to do with mounting and un-mounting the device but I'm new to command line and most other posts are over my head. What do i do to fix this error?
if it matters i'm running a script on the pi that writes to that flash drive
Your desktop (LXDE for Raspberry Pi) has spotted that you have inserted a USB disc and has tried to mount it. You can enable or disable this behavior by editing the file ~/.config/pcmanfm/LXDE-pi/pcmanfm.conf and changing the line
mount_removable=1
to set '0' instead.
You would get that error if there were more than one thing trying to mount your USB disc at the same time. The second to run will notice that the first has already started a job to mount the disc.
Are you running two copies of your desktop GUI? (You may not realize that you are, but if you have a VNC or XRDP service you probably will be.)
If that is the cause of your problem (and probably in any event) the message is harmless. Something will have mounted your USB disc (perhaps you can even see it in /media?) The only infelicity will be that your desktop won't show you the results (e.g. by displaying the drive in a file manager.)
Program counter holds the address of the instruction that should be executed next, while instruction register holds the actual instruction to be executed. wouldn't one of them be enough?
And what is the length of each one of these registers?
Thanks.
You will need both always. The program counter (PC) holds the address of the next instruction to be executed, while the instruction register (IR) holds the encoded instruction. Upon fetching the instruction, the program counter is incremented by one "address value" (to the location of the next instruction). The instruction is then decoded and executed appropriately.
The reason why you need both is because if you only had a program counter and used it for both purposes you would get the following troublesome system:
[Beginning of program execution]
PC contains 0x00000000 (say this is start address of program in memory)
Encoded instruction is fetched from the memory and placed into PC.
The instruction is decoded and executed.
Now it is time to move onto the next instruction so we go back to the PC to see what the address of the next instruction is. However, we have a problem because PC's previous address was removed so we have no idea where the next instruction is.
Therefore, we need another register to hold the actual instruction fetched from memory. Once we fetch that memory, we increase PC so that we know where to fetch the next instruction.
P.S. the width of the registers varies depending on the architecture's word size. For example, for a 32-bit processor, the word size is 32-bits. Therefore, the registers on the CPU would be 32 bits. Instruction registers are no different in dimensions. The difference is in the behavior and interpretation. Instructions are encoded in various forms, however, they still occupy a 32-bit register. For example, the Nios II processor from Altera contains 3 different instruction types, each encoded differently. See page 6 of ftp://ftp.altera.com/up/pub/Tutorials/DE2/Computer_Organization/tut_nios2_introduction.pdf
You can learn more about the Nios II processor's structure from the link above as well. It is a simple IP CPU. Of course Intel has their own specification/design and it will vary.
As you stated, the Program Counter (PC) holds the address of the next instruction to execute, and the Instruction Register (IR) stores the actual instruction to be executed (but not its address).
Related to the lenght of these registers, current machines have 64-bit PCs.
The length of the IR (from a logical point of view) depends on the architecture:
RISC machines usually have fixed-length instructions. For example, most SPARC instructions are encoded in 32-bit formats.
CISC machines (Intel, AMD) have variable-length instructions. For example, see the Intel® 64 and IA-32 Architectures Software Developer Manuals
As these machines are able to fetch, decode and execute several instructions every cycle, the physical implementation of the IR is not easy to describe in a few lines.