Community
cancel
Showing results for 
Search instead for 
Did you mean: 
mgolu
New Contributor II
1,879 Views

How to prepare OpenOCD scripts for D2000 - System and Data flash.

Hi, I have a product based on D2000 board. I want to send it to 10 clients of main for tests but on 100% I'm sure that the program and informations in flash will be changed during tests (for example new features and new device parameters). I want to prepare two Open OCD scritps first to flash CODE (32KB - 0x00180000) and second to flash DATA Region (4KB - 0x00200000) memory.

My question is how to prepare that kind of scripts for D2000 board?

0 Kudos
21 Replies
Pablo_M_Intel
Employee
141 Views

Hi Mark,

I'm not sure if you have followed the steps from the "Deploying a Project" section, if not I would suggest you to check this link first /community/tech/microcontrollers/blog/2016/04/06/limitations-and-known-issues-in-intel-system-studio-2016-for-microcontroller https://communities.intel.com/community/tech/microcontrollers/blog/2016/04/06/limitations-and-known-..., this includes some general information on limitations and known issues of System Studio for Microcontroller, once you've checked that click on the "Deploying a Project" hyperlink. In the first step you can see this file being compiled quark_d2000_onboard.cfg, I believe that's the file that you need to edit to generate different OCD scripts for your clients.

With the instructions from the second step you can start debugging your .elf file. So, take into account that the instructions from this section assume that you have already build this .elf file (accel.elf), if you haven't done that yet you'll need to open a third session to build it and then continue with the normal process.

Regards,

-Pablo

mgolu
New Contributor II
141 Views

Hi Pablo,

thank you for your answer and support. As I mentioned in my frist post I had two problems: the first one was "how to flash the code flash memory" and second "how to flash the data flash memory".

Thank you for the link about limitations attached to your post. I read it due to your instructions / as you suggest. In the meantime (at the weekend) I found an article: "Deploying a Project" and it was exactly what I looking for as far as my first question is conncerned. As you know the file is loaded into the memory via the "load" command (to 0x00180000 program space) and there is no possibility to load my own .bin file to the other memory space (for example 0x00200000 data flash space) using this command (additionally as far as I understand "load" command can work only with .elf files). Anyway as for me the first problem can be chceked as resolved because in the "Deploying a Project" article everything is described properly.

The second problem, I mean "how to flash the data flash memory", is still an open question for me because I made couple tests during the weekend but non of them was finished successfuly. At the begining, when I read quark_d2000_onboard.cfg file (which is loaded to OpenOCD) I found the "flash_rom" procedure which uses load_image command (there is pleace for file and for addresss) I thought that this can resolve my problem with loading the device settings into the flash data memory. But it did not help (there was a problem with "verify_image_offset" so in the next step I commented it out but with no effect either). In the next step I used telnet and I did not recieve any errors so I thought that all is ok but the data wasn't stored in the memory. In the last step I tried to use "mww" command and when I read this address via "mdw" command all was great I mean data was stored properly. My next question is why the "load_image" doesn't work?

Pablo_M_Intel
Employee
141 Views

Hi Mark,

We are still investigating your case. We will do some more research and will get back to you soon.

Regards,

Pablo

Pablo_M_Intel
Employee
141 Views

Hi Mark,

I'm wondering if you could provide your code here so we can take a look at it. If you can't share it here in the Community for privacy matters, you can talk with your Intel representative and tell him to help you open an email ticket (a Quark email ticket), that way you can share your code without issues. We would like to see what you have done so far, it will be easier for us to help you that way.

Once you have opened the ticket or if you have any questions regarding this process please let us know.

Regards,

-Pablo

mgolu
New Contributor II
141 Views

Hi Pablo,

thank you for your answer and I'm very sorry for my delay but I was on BT last couple days. Reference to my last problem there is no source code because I want only write single .bin file (genereted form external program for example Neo Hex Editor) into flash data region (from address 0x00200000) I want to keep there device settings. I test mentioned commands "load_image" and "mww" from telnet command window

Michelle_C_Intel
Employee
141 Views

Hi Mark,

With reference to the 'flash_rom' function this should not be changed as it is specific to flashing the ROM to the board.

You could write a new function -- for example the below function will flash a .bin file to address 0x00180000

proc flash_app { app_file { address 0x00180000 } } {

init

echo "Setup clock"

clk32M

echo "Start flash"

load_image $app_file $address

echo "Start verify"

verify_image $app_file $address

echo "Reset target"

reset halt

echo "All done"

}

Here are the commands I use to initiate the flashing ...

mgolu
New Contributor II
141 Views

Hi Miechelle,

thank you for fast response. Of Course you have right and I prepared and add new function for my "quark_d2000_onboard_cust.cfg" file it works very good. But I have also need to write my some dev settings into flash data region which starts from 0x00200000 address. But when I try to do this (I add another function with changed address) it doesn't work.

Of course this "dev_set.bin" it is file prepared by my self in Hex editor and it contains only 16B.

Michelle_C_Intel
Employee
141 Views

Hi Mark ,

It looks like the Data flashed ok - Is the issue that you are unable to read it ?

--Michelle.

mgolu
New Contributor II
141 Views

Hi Miechelle :-),

yes I know that the logs looks ok but these 16B from this .bin file aren't saved in flash data region after this operation. I can read data from memory (for example from address 0x00200000, 0x00200004 etc) and send it on UART but they are not changed.

I can write a step-by-step what I'm doing maybe it will be helpful?

Mark

Michelle_C_Intel
Employee
141 Views

Hi Mark ,

Yes , please send on the steps you are doing so we can try to replicate.

--Michelle

mgolu
New Contributor II
141 Views

Hi Michelle,

I'm very sorry for my delay but during the tests one of my application which is based on D2000 board I found some issue which need to be repaired very fast.

Anyway I just want to write that I will continue this topic in next few days. I'm verry sorry once again but I need to resolve this second much more important problem.

Michelle_C_Intel
Employee
141 Views

Hi Mark,

Did you erase the contents before you did the last load ---- 'del_flash0' ?

Have a look that the 'flash_access' example provided in ISSM -- are you able to read the DATA Flash OK id you write using that method ?

/* Flash physical address mappings */

# define QM_FLASH_REGION_DATA_0_BASE (0x00200000)

# define QM_FLASH_REGION_SYS_0_BASE (0x00180000)

# define QM_FLASH_REGION_OTP_0_BASE (0x00000000)

regards,

-- Michelle.

Michelle_C_Intel
Employee
141 Views

mgolu
New Contributor II
141 Views

Dear Michelle,

thnk you :-) I'll test it today. Before we will contiune our main topic I have some question about Flash Data region (It is directly connected with main problem of this thread of course) . In mentioned sample code (FLASH) I found commentary as below:

/*

* For Quark Microcontroller D2000, there is 1 flash controller.

* Controller 0:

* | Component | Size | System start address

* | System ROM | 8KB | 0x00000000

* | System Flash | 32KB | 0x00180000

* | Data region | 4KB | 0x00200000

*/

so as far as I understand First 8KB from address 0x00000000 it is the ROM part. Second: it is a place for the application code 32KB starting from 0x00180000 and the last third part - it is 4KB (non-volatile memory) which is not cleared during the loading application code process. By following this thought I wrote a simple application which loads couple bytes (for example device address, serial number of device etc [code below] ) into the flash data region (starting from 0x00200000). The data are constantly connected to the device/board. In the next step I load the second application into my borad (this application will read and print parameters of the board written into "Data region" memory from the previolus application) and as far as I understand this board parameters saved in the memmory region from 0x00200000 address should stay and can be readed by the second application propely? Am I right ?

/*CODE OF FIRST APPLICATION - PARAMETERS LOADER*/

# include "qm_flash.h"

# include "qm_common.h"

# include "qm_identification.h"

# define NUM_DATA_WORDS (0x03)

# define WR_FLASH_ADDR (0x101C) /*4096 */

# define WR_FLASH_ADDR_IDNUM (0x00)

# define SIZE 4

# define FLASH_ADDR 0x00200000

# define SWAP_UINT32(x) (((x) >> 24) | (((x) & 0x00FF0000) >> 8) | (((x) & 0x0000FF00) << 8) | ((x) << 24))

# define FIRST_DATA_FLASH_PAGE (0x00)

# define MASS_ERASE_INCLUDE_ROM (0x00)

# define US_COUNT (0x20)

# define WAIT_STATES (0x01)

static uint32_t flash_page_buffer[QM_FLASH_PAGE_SIZE]; /*512 slow 32bit czyli 4kB*/

typedef struct

{

uint32_t devAddress;

uint8_t devSerNum[16];

uint8_t secData[16];

uint8_t thirdData[8];

uint16_t secCnt;

uint16_t cnt;

} DeviceParams;

int main(void)

{

qm_flash_config_t cfg_wr, cfg_rd;

static DeviceParams DevAppParam =

{

.devAddress = 0x07,

.devSerNum = {0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0x10, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66},

.secData = {0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0x10, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66},

.thirdData = {0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88},

.secCnt = 123,

.cnt = 321

};

DeviceParams ReadedData = {0};

cfg_wr.us_count = US_COUNT;

cfg_wr.wait_states = WAIT_STATES;

cfg_wr.write_disable = QM_FLASH_WRITE_ENABLE;

qm_flash_set_config(QM_FLASH_0, &cfg_wr);

qm_flash_page_erase(QM_FLASH_0, QM_FLASH_REGION_DATA, FIRST_DATA_FLASH_PAGE);

qm_flash_page_update(QM_FLASH_0, QM_FLASH_REGION_DATA, WR_FLASH_ADDR_IDNUM, flash_page_buffer, &DevAppParam, 0xC);

/*Read and print to UART saved data*/

uint8_t y =0;

QM_PRINTF("*************************************************************\n");

QM_PRINTF("Device config.:\n");

QM_PRINTF("devAddress: \t\t %X \n", *(uint32_t *)0x00200000 );

QM_PRINTF("devSerNum: \t\t %X-%X-%X-%X \n", SWAP_UINT32(*(uint32_t *)0x00200004), SWAP_UINT32(*(uint32_t *)0x00200008),

SWAP_UINT32(*(uint32_t *)0x0020000C), SWAP_UINT32(*(uint32_t *)0x00200010));

QM_PRINTF("secData: \t\t %X-%X-%X-%X \n", SWAP_UINT32(*(uint32_t *)0x00200014), SWAP_UINT32(*(uint32_t *)0x00200018),

SWAP_UINT32(*(uint32_t *)0x0020001C), SWAP_UINT32(*(uint32_t *)0x00200020));

QM_PRINTF("thirdData: \t\t\t %X-%X \n", SWAP_UINT32(*(uint32_t *)0x00200024), SWAP_UINT32(*(uint32_t *)0x00200028 ));

QM_PRINTF("\nApp config.:\n");

QM_PRINTF("cnt: \t\t %d (DEC) \n", *(uint16_t *)0x0020002C);

QM_PRINTF("secCnt: \t %d (DEC)\n", *(uint32_t *)0x0020002C >> 16);

QM_PRINTF("AppParams_t: \t\t %X \n", *(uint32_t *)0x0020002C );

QM_PRINTF("*************************************************************\n");

return QM_RC_OK;

}

/*

ADDED -w to app.mk file in section "# Build C files in APP_DIR" as below:

# Build C files in APP_DIR

$(APP_DIR)/$(BUILD)/$(SOC)/$(OBJ)/%.o: $(APP_DIR)/%.c libqmsi

$(call mkdir, $(APP_DIR)/$(BUILD)/$(SOC)/$(OBJ))

$(CC) $(CFLAGS) -c -w -o $@ $<

*/

mgolu
New Contributor II
141 Views

When I flash the board with the code mentioned above everything works fine. please take a look at the screen prints below (especialy the memory tab). We can reset the board, cut off power etc evertything is great because the data is saved properly in flash (as on screen print). The problem is when I want to flash the board with the application code (or any other - can be the same as above with commented lines about errase and update flash) which in the first step of work is reading the board parameters (mentioned above couple bytes starting from 0x00200000 address). After any flashing operation the first eight bytes (starting from 0x00200000) are totaly different but the rest of them are ok. Why? What is the reason?

ERASING STEP

PROPERLY SAVED DATA

AFTER FLASHING

Michelle_C_Intel
Employee
141 Views

Hi Mark,

I can re-produce the issue you are seeing here -- I'll take a look though the code and see if there is anything that could be causing this.

--Michelle.

MHibb
Beginner
141 Views

Hi both,

I thought I would try writing from openOCD directly, through the command line. Here is what I did, under Windows 10:

Open a command prompt, navigate to

C:\IntelSWTools\ISSM_2016.1.067\tools\debugger\openocd

run the command

bin\openocd -f scripts\board\quark_d2000_onboard.cfg

Run putty, and opened a telnet session to localhost port 4444

In the telnet session typed

reset halt

mdw 0x200000 256

This displayed

> mdw 0x200000 256

0x00200000: 7e217dff 7e4a7e4a ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff

0x00200020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff

So next I went and wrote some data, any data, to that flash. I chose to write the contents of one of my Makefiles, as it was only a couple of KB.

load_image C:\\d2000-workspace\\test1\\Makefile 0x200000 bin

Then I looked at the content again

> mdw 0x200000 256

0x00200000: 20230a23 79706f43 68676972 63282074 30322029 202c3631 65746e49 6f43206c

0x00200020: 726f7072 6f697461 20230a6e 206c6c41 68676972 72207374 72657365 2e646576

ok, looks good. Lets shut down openocd, power cycle the board and read memory again

> mdw 0x200000 256

0x00200000: 20230a23 79706f43 68676972 63282074 30322029 202c3631 65746e49 6f43206c

0x00200020: 726f7072 6f697461 20230a6e 206c6c41 68676972 72207374 72657365 2e646576

So, at least on my board, the OTP data flash appears to be ok, and the bootrom is not interfering with access to it.

One thing I should point out is that I am using the latest QMSI 1.1 bootrom and ISSM tools; if you are not, it's worth installing them anyway to get the latest tools.

I hope that helps...

Regards,

Mike

(openOCD user manual can be found on the Internet, I got my copy from here: http://www.fdi.ucm.es/profesor/mendias/PSyD/docs/OpenOCD%20User%E2%80%99s%20Guide.pdf http://www.fdi.ucm.es/profesor/mendias/PSyD/docs/OpenOCD%20User%E2%80%99s%20Guide.pdf )

Mike_H_Intel
Employee
141 Views

Hi Mark,

I've checked with the software team; there is an explanation.

The first 8 bytes of Data Flash are used by the default bootrom code to store calibration data for the on-silicon oscillator. So the simple answer to your question is skip the first 8 bytes of Data Flash.

This functionality is optional; it is only useful to you if you intend to use the silicon oscillator at a frequency other than 4MHz or 32MHz. For those two frequencies, the calibration data is computed in the factory and stored in the 8KB OTP flash. To permit operation at 8MHz or 16MHz from the silicon oscillator, the bootrom code performs a self calibration relative to the external crystal, and stores the calibration data in the first 8 bytes of Data Flash. This operation is performed once only. Check bits in the calibration data stop the bootrom repeating this on each boot.

If you do not want this feature (perhaps to speed up the boot process very slightly) you can remove the code from the bootrom. You can see the code here, it starts in the file

firmware\bsp\1.1\soc\quark_d2000\rom\rom_startup.c

if ((QM_FLASH_DATA_TRIM_CODE->osc_trim_32mhz &

QM_FLASH_TRIM_PRESENT_MASK) != QM_FLASH_TRIM_PRESENT) {

boot_clk_trim_code_setup();

}

Regards,

Mike.

mgolu
New Contributor II
141 Views

Hi Michelle and Mike,

sorry for my delay but I was on short vacation. Mike thank you for your answer and explanation it was very helpful - I'll just leave unused first couple byte as you suggest.

As Imention on previous page I want also write this data (mentioned device settings) on easier way. Can I prepare binary file (for example in hex editor program) and write it directly into flash data region starting from 0x0020000C using for example open OCD command / script?

gest.

Mike_H_Intel
Employee
11 Views

Hi Mark,

You can load your binary file like this. Run openOCD and telnet as I showed above first. Then, I assume you have a file containing your binary data - mike.bytes in my example below, which contains the four bytes 'mike'.

Load it into data flash memory at address 0x20000C by issuing the following command:

load_image c:\\mike.bytes 0x20000C bin

Confirm by reading flash memory back:

mdw 0x200000 256

0x00200000: ffffffff ffffffff ffffffff 656b696d ffffffff ffffffff ffffffff ffffffff

One thing to note: when specifying file paths in openOCD under windows, as above, a double backslash is required in the path separator.

Hope that helps.

Regards,

Mike.

Reply