SparkFun Forums

[bernardf]

Hi.

To be able to correctly erase bank 1, the memory layout must be changed: the last two entries of "str7x_mem_layout mem_layout" (line38 in str7x.c) must end with "0x100' and not '0x10'. (Sorry it seems that I can't copy/paste correctly from Emacs )

This is because the bits for bank 1 are not contiguous from those of bank 0, there is an empty byte in between.

Cheers,

Bernard

[Dominic]

Hello Bernard,

you're right that the bits in the protection register aren't contiguous, but I believe the code takes care of this:

Code: Select all

for (i = 0; i < bank->num_sectors; i++)
{
	if (retval & (mem_layout[i].reg_offset << i))

It shifts the reg_offset to the right by the sectors number. That way, the first 8 sectors, belonging to bank 0, result in bits 0 to 7, while the last two sectors (#8 and #9), result in 0x10 being shifted to bit 16 and 17.

Regards,

Dominic

[bernardf]

Hello Bernard,

you're right that the bits in the protection register aren't contiguous, but I believe the code takes care of this:

Code: Select all

for (i = 0; i < bank->num_sectors; i++)
{
	if (retval & (mem_layout[i].reg_offset << i))

It shifts the reg_offset to the right by the sectors number. That way, the first 8 sectors, belonging to bank 0, result in bits 0 to 7, while the last two sectors (#8 and #9), result in 0x10 being shifted to bit 16 and 17.

Regards,

Dominic

If you shift left 8 times 0x10, you have 0x00001000: the '1' is on bit 12, not 16 since in 0x10 the '1' is on bit 4.

Bit 16 is 0x00010000 (4 zeros after the 1, not 3!). So to reach it by 8 shift, you must start by a 1 bit in position 8 (8+8=16), hence the 0x100 value.

Bernard

[Dominic]

Hello Bernard,

of course you're right. I meant to write bits 12 and 13, but 16 and 17 are the correct positions.

I'll change the code accordingly.

Regards,

Dominic

[bernardf]

Hi.

I ran into different problems today and lost amounts of time on them. Here they are:

- first, the bank numbers. In OpenOCD, there is only one bank for STR7X, having sectors 0 to 9. The STR7x is designed with 2 banks, bank 0 with sectors 0-7 and bank one with sector 0-1. If you try, after having patched 0x10 to 0x100, and try to do 'flash erase 0 0 9', it will fail: it seems that the STR7x refuses to erase sectors in both banks at the same time. The flash error register (FLASH_ER) is then set to 0x00000041. So to be the closest to the datasheet, I suggest that Openocd defines 2 banks for STR7X, so no one like me will spend hours trying to erase sectors in different banks at the same time even when the correct bits in the correct registers are correctly set

Note also that in the current version, there is no error message if FLASH_ER is set to 0x41: only the timing difference between a successfull erase or a failed one (the successfull is longer!) tells the user that the operation went fine or not.

- Then Openocd does not clean FLASH_ER before doing flash operations: if this register is not null, all flash operations will fail! So you do a mistake once, or the tested program on the target leaves the register dirty and then you can try anything, no flash command will correctly work afterward! I suggest that all flash operations start by cleaning FLASH_ER to zero.

- The STR7 supports two kind of protections: write protection and debug protection. Instead of 'protected', can we have 'write (un)protected' in the 'flash info' report?

- Someone working with me is seeing how to speed up the write process (with the 'ram' trick. In fact the time is spend expecting results from the USB, he found a 6ms between two queries. It appears that the 'ram' speedup is a speedup because registers' flags will be processed inside the chip and not in openocd so queries over USB will be much less numerous).

Bernard