Hi Marni- I want to follow-up on this as I have not seen you publish a poll. Ben suggested you try and post from one of the actual Community Groups (you can see all the Groups here) instead of clicking on 'Create a Poll' from the top menu bar. The error message is a known bug and below is the workaround.
For example if you would like to post a poll in the IoT Group - go to the Internet of Things Group and click on 'Create a Poll' from the right Actions.
Cheers!
Brad
Hi jvanmont,
we usually treat addresses as VA=LA, because almost applications are single task scheme. Do you ask how to realize a multi-task system using address translation from VA to LA? I think you can use PIC (position independent code) to make an address translation by using the following GCC options.
-fpic
-msingle-pic-base
-mpic-register=reg
The default base register is r10 (a.k.a. sll). By changing the base address value, you would able to realize an address translation.
Best regards,
Yasuhiko Koumoto.
Hi caotianxiang,
regarding 1, it seems almost all the intrinsic were abandoned in the ARM Compiler 6. However, you can make the equivalent functions by using the __attribute__((always_inline)) function attribute and the __asm keyword (i.e. inline assembler).
Regarding 2, I am afraid the "dspfns.h" is no longer supported in the ARM Compiler 6.
Anyway, I am not familiar to the armcc or armclang and my answers might be wrong.
Best regards,
Yasuhiko Koumoto.
Thank you for code snippet sir,
i followed ur sequence , but the story remains same.
IDCODE success,
ABORT write success,
CTRLSTAT = 0xffffffff with parity error ,
i got same response even i changed pullup 10k to 100k.
This is a single thread application. I compiled an empty memory array in some sram section. I review my memory mapping and see that this section is loaded from empty flash region? I wonder why it need his load address from flash?
This is the array in sram:
static U32 extMem[GUI_NUMBYTES / 4] __attribute__((section(".ExtRAMData")));
... Uhm wait ... You use STM32F4 Discovery, right ?
If so, did you remember to disconnect the on-board SWD programmer ?
-If not, it might interfere with your results.
I tried grabbing the data using my analyzer, and I can't seem to map them properly to the documentation and experience of for instance Mark.
These are the first 400 bits of the transfer:
11111111111111111111111111111111111111111111111111111011110011110011111111111111
11111111111111111111111111111111111111111100101001011001110111000101000000001011
10101000011011000110000000000000000000000000000000100111100101011000100000000000
00000000000000000101001011000110000000000000000000000000000001111001100011011000
10000111100000000000000000000000001111100110000000000000000000000000000000000001
Note: When using HLA_SWD on STM32F4, I get 53 leading ones and 53 trailing ones, but when I use JTAG-lock-pick Tiny 2 with LPC1751, I get 50 leading ones and 50 trailing ones.
What looks odd to me, is that it looks like there is no turnaround!!
-But also according to the documentation found here, there should be turnaround: http://www.arm.com/files/pdf/Low_Pin-Count_Debug_Interfaces_for_Multi-device_Systems.pdf
I get IDCODE 0x2BA01477 for both STM32F4 (which is a Cortex-M4 device) and LPC1751 (which is a Cortex-M3 device).
Here's a similar session with JTAG-lock-pick Tiny 2 and LPC1751:
11111111111111111111111111111111111111111111111111011110011110011111111111111111
11111111111111111111111111111111111100101001011001110111000101000000001011101010
00111000000110011011110000000000000000000000000000000000001011000110010000010000
00000000000000000111101110010101100110000010000000000000000000000000011011000110
00000001000000000000000000000000011110010101100110000000000000000000000000000101
In both cases, it seems there's no turnaround clock. So I believe that right after sending the last bit, before changing the SWCLK to LOW, you could try and change the SWDIO direction to input, then issue the SWCLK_LO and have 0 turn-around clock cycles.
According to all the documents I found, it seems that data are sampled on the rising edge of SWCLK, thus changing the direction should be done right after you've sampled the data.
So far, I have been unable to do a test with the JTAG-lock-pick Tiny 2 connected to the Discovery board, but if I get it set up, I'll post the output here as well.
On the to do list it suggests connecting via your mobile device. I tried (iPhone 6+ web browser), but it doesn't seem to count. Any ideas?
thank you, Brad.Happy New Year!
Hello Dcblack,
Please read this document, hope it can help you:
Mobile App, iOS, Android - Guide
Best Regards,
Ben
OK335xS-2 开发板的活动，工程师朋友的项目进展比较顺利。
Great, 希望更多的朋友能得奖
这个看上去很不错啊
让James用好了给大家说说好玩不好玩
Hi,
I am trying to understand the startup code and assembly language (more for learning and not for a specific project) for ARM Cortex M4.
I made a project in KEIL with just one assembly file and added a stack declaration and a vector table there. It was based on STM32F4 startup file in the Keil software pack.
In the reset handler I added just a couple of lines of code to load an immediate value into R0 and R1.
The program worked fine in the simulator however there was a warning issued during build - Warning: L6305W: Image does not have an entry point. (Not specified or not set due to multiple choices.).
Searching on the net, it led me that the ENTRY directive is required so the code knows where to start. So there should be either an ENTRY directive if programming in pure assembly or there should be __main symbol if programming in C.
Adding and ENTRY directive after the RESET code section helped eliminate the warning. But I wonder that even without ENTRY directive, the code worked properly. So what is the significance of the directive, if any? Or it is necessary for the ARM7 etc. and not for Cortex M?
Thanks,
Gopal
According to related manuals , I see that A7 is able to send 8-bits, 16-bits, 32-bits, and 64-bits exclusive access.
I'm wondering that if it's able to send a 128-bits exclusive access or not.
thank you for reply sir,
i got the CTRLSTAT register correct , The problem was with the parity bit calculation , I corrected that one. Now I am able to halt and reset the core from host to target successfully. Now i am trying to write data into flash memory region. may i know an algorithm or flowchart approach to write hex file to flash memory??
when we use comliler6 build a Qcom cortex-a53 program，it display· some error like：
armclang: error: unsupported option '--apcs=/ropi/rwpi'
armclang: error: unsupported option '--lower_ropi'
armclang: error: unsupported option '--lower_rwpi'
armclang: error: unsupported option '--protect_stack'
how should to deal with this？
And our board will use mali only for accelerating fbdev /x11 rendering and video decoding.
Just to clarify this a little more - the Mali-T600/T700 parts are 3D graphics accelerators for OpenGL ES, and GPGPU accelerators via OpenCL. These generally have nothing to do with video decode; while it is possible to implement a video codec in "software" using OpenCL to accelerate portions on the GPU, many SoCs will have a dedicated video decoder (such as Mali-VE500) which is more energy efficient at video encode/decode. This will generally need a separate driver - it is not part of the 3D GPU driver stack.
HTH,
Pete
Maybe will need some time to make it work.
Thanks and happy New Year 2015.