I am migrating to using Vivado and want to add interupt generation to my custom AXI perph. In ISE I have previously done this by using one of the templates given in the AR records (http://www.xilinx.com/support/answers/51138.htm). What is the best way to achieve this in Vivado?, do I need to add the interupt signal port and controller IP into the AXI perph in a similar manner?
Just to clarify with a simple example of what I want to acheive:
1) Send two numbers to the AXI perph
2) Does some operation (i.e. add) and puts the result in the result register
3) An interupt is generated in the perh to tell the CPU the result is ready.
The documentation is very sparse on this topic
So far I have enabled the Core0-nIRQ port on the Zynq system, I just don't know the intermediate steps to interface with this port, from the custom AXI perh.
Sam
If you are using Vivado's "Create and Package IP", click the box to "Enable interrupt support" on your peripheral.
You already enabled the interrupt on the Zynq side, so now you should be able to connect them.
I find the whole "Create Block Design" GUI to be annoying, so I just use HDL to define the top level and Vivado tcl scripts to automate the coregen runs.
Related
We want our device (STM32-F446RE running FreeRTOS + Telit ME310G1 modem) to communicate to the AWS cloud. We are trying to follow the Cellular Interface Library Demo, in particular following this- diagram
We are using coreMQTT Agent, MbedTLS libraries, the amazon communication interface implementation for UART and amazon UART API implementation.
UART using 115200 baud rate.
Currently failing on the Cellular_Init function when trying to send the first AT command to the modem, specifically when calling the HAL_UART_TRANSMIT_IT function from the above comm interface send function. While debugging we see that the USART1_IRQHandler is called infinite times and nothing is sent through the UART communication.
We are using the default handler, do we need to implement it in any way?
void USART1_IRQHandler(void)
{
HAL_UART_IRQHandler(&huart1);
}
Any help will be appreciated.
Thanks in advance,
Guy
Sounds like the UART line from HW point of view are not in a good state (High).
Did you check and ensure that the Power On sequence is done correctly? (Power On telit pin shall be high).
I expect you have some logic to translate the 1.8v to 3.3v and vice versa.
Can you check by measuring the different voltage that everything is OK?
If you verified all the point above.
Do you perform a reset on the telit side before starting the AT communication?
This ensure that you don't leave the module into a data mode where no AT commande are possible
Yacine
I'm doing a bit of research on Intel Pin. I'm looking to see if there is a way of attaching a Pin tool to an existing process using the Pin API.
I can see there is a way of running the pin executable on an already running process using pin.exe -pid <process_id> but I can't see anything in the pin documentation.
EDIT: As per a previous comment, I'm updating the question with an example.
The problem I'm trying to solve is instrumenting an injected process (this is for malware analysis).
If the process/binary I'm instrumenting creates a child process then pin can seamlessly attach itself to said child process. Wonderful!
If, however, the binary process/binary I'm instrumenting injects into another process (i.e. OpenProcess > VirtualAllocEx > WriteProcessMemory > CreateRemoteThread) then Pin will NOT attach to the injected process. I need to be able to tell pin to attach dynamically at runtime.
You'll have to implement something like that yourself - instrument the system calls and if you see an injection pattern, attach pin to the process.
The STM32 family of microcontrollers features a read-out protection feature so proprietary code can't be read out via the debug interface (JTAG or SWD).
Using OpenOCD, how can I enable/disable the read-out protection via a SWD/JTAG interface? How secure is the RDP read-out protection?
If possible, please give an answer valid for the entire STM32 family.
RDP levels
First, you have to know which level of readout protection you want to set (refer e.g. to section 3.7.3 of the STM32F4 reference manual):
RDP level 1: This level is reversible. Once you disable it, the system memory is mass-erased and you can re-program
RDP level 2: This level is irreversible and disables the debug interface altogether. The only way of updating your firmware is via some bootloader mechanism.
Usually you want to activate RDP level 1. In order to avoid mistakes that will certainly brick the microcontroller, I will not show how to enable RDP level 2 in this answer. Refer to the reference manual for details.
Activating it using OpenOCD
The activation feature is actually built-in into OpenOCD using the lock command. Just like executing the program command to flash your firmware, you can use the stm32f1x lock command (or stm32f2x lock for STM32F2/F4) to activate it.
A typical OpenOCD configuration file would look like this (you need to flash the correct firmware before running this):
# Set RDP to level 1
init
reset halt
stm32f1x lock 0
reset halt
exit
Note that the readout-protection will only be in effect once the microcontroller is reset or powered off (that's why there's a second reset in the command sequence).
A typical OpenOCD call could look like this:
openocd -d0 -f stlink-v2.cfg -f ocd-stm32f0.cfg -f ocd-lock.cfg
where ocd-lock.cfg contains the command sequence shown above.
Once activated, you can verify that the RDP is active by trying to flash the MCU using your usual programming command sequence
Deactivating RDP
Deactivating it is just as simple: Just use stm32f1x unlock (or stm32f2x unlock for F2/F4 devices) like this:
# Set RDP to level 0
init
reset halt
stm32f1x unlock 0
reset halt
exit
How secure is it?
That's a tough question that can't really be answered without additional information. One summary answer I can give is that it's pretty secure if you assume the protection has no inherent bugs and someone uses software tools only.
One of the most popular methods of resetting the RDP bit without mass-erasing the flash is to disable the RDP with a laser. Given the fact that the STM32 family is not a family of dedicated security microcontrollers with specific countermeasures, this is rather easy if you have the right equipment and sufficient experience in this area. Even some specific security MCUs have some security issues, see e.g. the Security from the IC backside talk. However, most low-level attackers will usually refrain from the cost of doing so.
Another solution is using Segger Jlink 6.60c (or later if available)
with J-Link unlock STM32 software.
Just run it, it will notify about following: "If read protection of the device is enabled, reset the option bytes will cause a mass erase". Click OK. It will ask for device family. Enter device family (my choice was 12 for STM32L4R9ZI) and press Enter.
If all good the output will be like this:
Please select the correct device family: 12
Connecting to J-Link via USB...O.K.
Using SWD as target interface.
Target interface speed: 1000 kHz.
VTarget = 3.396V
Reset target...O.K.
Reset option bytes to factory settings...
Resetting FLASH_OPTR...
Reset target...O.K.
Reset target...O.K.
Resetting Write protection (WRP) and PCROP...O.K.
Reset target...O.K.
Option bytes reset to factory settings.
Press any key to exit.
I have a Netduino Plus with at transeiver attached via SPI. I would like to reset the transiever every time the Netduino restarts. Is it possible to programmatically power on/off the 3V3 pin?
I would recommend using a FET (controlled by one of the I/O) pins to enable/disable 3V3 power to your transceiver. When you say transceiver, I think "more than a few mA" :)
BTW, we took this feedback into account with the new Shield Base module for Netduino Go. It has an integrated FET on both 3V3 and 5V power headers, so you could enable/disable power to your shield in code. Once the new Ethernet go!bus module ships and the Shield Base comes out of beta (soon), your solution can be redeployed to Netduino Go + Shield Base with few/no code changes.
Chris
Secret Labs LLC
Looking at the circuit diagram ( http://www.netduino.com/netduinoplus/schematic.pdf ), I can see only the Micro SD Card Slot having its power controlled programmatically. You could rig up a relay to control it (via a transistor, of course) instead, or if the transceiver uses less than 130mA (the current limit of the device shown: http://www.datasheetarchive.com/BSS84W-7-F-datasheet.html) you could copy the circuit from the Netduino Plus. Buying a relay shield looks like overkill, but you might have other uses for it.
Have you looked into resetting the transceiver programmatically instead of the brute-force method of power-cycling it?
Just to provide another view. You could use a transistor powered off the netduino RESET line, this will reset the device every time the netduino reboots. Or you can just link the transistor to a spare digital pin and power it in code..
What specific SPI device are you using? You mention that it's a transceiver but we could probably provide better information if we know the exact part number. If your device requires less than 8mA the Netduino Plus specs seem to indicate that one option could be using a digital output pin as the power source.
Unfortunately Secret Labs don't use exactly the language I'd expect and call out the sink and source current maximums so I would contact them directly first to see if you risk blowing your chip. I'll see if I can get an answer from them and amend this post if/when I do.
Update: Sink and source current is the same on the Netduino. See my post on their forums about sink vs. source current for a more in depth explanation. So, if your device can run off of just a few milliamps you should be able to use a digital I/O pin to power it.
Also, a lot of devices have enable pins. You can usually reset them with that line instead of pulling the power if that helps. Sometimes with flaky hardware it is better to pull the power though.
I have embedded firmware which have terminal over serial transmission. I am doing command from terminal which waits data (text file) which it should save to flash chip. However, writing flash is much slower than terminal transmission.
Text file may be pretty big (many kB), so in small embedded environment I cannot simply dump it to RAM. I though if it possible to communicate with standard terminal emulator (which have drag/dop support for files) to pause transmission every time when write buffer is full and tell continue again after write is done? I haven't find anything which may help me throught this.
Well, offcourse I can make PC frontend which understands this trick, but in basic level it should be nice if all function can be used through normal terminal if needed.
For a basic serial connection you could see if the hardware supports flow control. This would be the CTS, RTS lines (clear to send, request to send).
http://en.wikipedia.org/wiki/RS-232_RTS/CTS#RTS.2FCTS_handshaking
However many simple embedded systems do not implement this type of flow control.
If the hardware does not support flow control, then you will have to look at using some form of software flow control. You maybe able to implement the Xon/Xoff flow control ( http://en.wikipedia.org/wiki/XON/XOFF ) or could implement a simple file transfer protocol, like XMODEM, or ZMODEM, or even tftp. This depends on what your terminal can support.
I always use XMODEM when programming data into FLASH via a serial link from a PC. When using XMODEM it only sends one data packet at a time and waits for you to acknowledge the packet before sending the next one.
This means we control the flow via software on the receiving side:
Get packet ->
Write packet ->
Ack packet ->
Repeat util done...
XMODEM can be implemented on the smallest of devices (less than 1K RAM) and the code is very simple. All serial terminals support XMODEM (upto windows XP ship with an XMODEM capable terminal). XMODEM requires no special hardware.
Here is the spec.
Here is an example implementation.