When P2.3 has been low ,how to switch mode between Downloader and Normal Run?
See Figure 38 page 187 of UG-498 - ADuCM320 Hardware Reference manual for the exact details.
But basically the easiest way is if K1B0, K1B1, K2B0 and K2B1 are all erased (i.e. 0xFFFFFFFF) and P2.3 is low during a reset or power up. This is the case when parts arrive from ADI or after you do a mass erase.
For further understanding you can basically think of the K1Bx keys as the ones used to tell which flash block has a newer firmware and then K2Bx are used to tell if the firmware is valid or not.
1.In my firmware, when ready to enter Downloader mode,i will erase K1B0,K1B1,K2B0,K2B1,then set the soft reset;
2.In my download application,after the firmware download is complete,application will set "K1B0 > K1B1" and "K2B0 = 0";then reset,the aducm320 will go to NORMAL RUN;
Rigth above operation?
Today,i verify mdio download.
I made a mistake; In my download application,seting "K1B0 > K1B1" and "K2B0 = 0"; but i downloaded a firmware that can not erase K1B0,K1B1,K2B0,K2B1;
Now,ADuCM320 can not enter Download mode,and can not enter with JLINK;
How to do to solve this problem?
The part is either in download mode where you can access it via MDIO or it's running user code where jlink should be accessible unless your code specifically disables serial wire access.
What's the error you are seeing?
for your previous question, yes you can erase K1B0,K1B1,K2B0,K2B1 and do a software reset to enter download mode.
2, when you download a new firmware you need to ensure that K1B0 > K1B1" and "K2B0 = 0"; is part of the hex file otherwise the kernel mdio downloader will not jump to the correct firmware.
If you want to use the block switching features then you need to follow the flow documented in Figure 38 and the associated documentation
Thank you for previous support.
A: Why do we"need to ensure that K1B0 > K1B1" and "K2B0 = 0"; is part of the hex file" ?
If this has been done prior to entering swdownload (e.g by homst commanding device to store correct values and then set p2.3=0 and reset) and new firmware has written the correct values and this page was left untouched, there shouldn't be an issue. Correct ?
B: Another question:
In AN-1310.pdf it says:
5 Set address 0x3000 + page number (Pages need not be consecutive.)6 Write Data Next 2 bytes to program Increment flash address by 2.
1. page size is 256*8 = 2048 correct ? and there are 64 pages per image (120K)
2. Why do we have to increment the address by 2 it has been set already and the consecutive frames are only MDIO data frames
A, this was based on the assumption that P2.3 is hard wired to 0, so the keys are modified in such a way that a reset will cause the downloader to be entered and then as part of the download process you program the new keys and then reset so that the new firmware is switched to, if you didn't program the new keys as part of the download process the downloader would be entered again.
However if you have control over P2.3 what you said is correct.
1.Yes page size is 2k. The downloader doesn't actually have a concept of images. So it can download to the entire 256kB of flash.Your application would have to decide if it needs to program to flash 0 at 0x0 or to flash 1 at 0x20000
2. That is just a comment to say that the internal counter that keeps a track of the bytes being programmed is incremented by 2. You don't need to do anything special there.
Thank you for all the elaborations
One additional question is regarding little/big endian.
Thus when programming the 8 bytes from the hex file such in the below first line (taken from a working program file)
would it be every 2 bytes High Low, High Low etc ? or a different order
That is a very good question which isn't clear to me in the protocol spec.
The question has 2 parts.
1. How does the ADuCM320 program the data received over MDIO?
2. How is data stored in a hex file.
I'll let you figure out the second part as it's industry standard.
1. to program the word 0x1122334455667788 in flash send the following over MDIO
I think that's pretty much what you said as well.
Thank you for the response;.
I used the following description to analyze the hex file which is quite clear
GENERAL: INTEL HEX FILE FORMAT
Now another question which doesn't seem to be addressed in ADU documentation -
The Hex file includes a special record which is specific for
It is the Program START address (below is line for hex file):
Where has this to be programmed ? It seems that the bootloader will always start at 0 of active Flash (according to registers)
Thank you for continued support
Retrieving data ...