STM32F103ZET6 support

Any other STM32 based boards
User avatar
Pito
Posts: 1592
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: STM32F103ZET6 support

Post by Pito » Thu Nov 24, 2016 8:51 pm

W25X10, W25X20, W25X40, W25X80
Family of Serial Flash Memories
W25X10: 1M-bit / 128K-byte (131,072)
W25X20: 2M-bit / 256K-byte (262,144)
W25X40: 4M-bit / 512K-byte (524,288)
W25X80: 8M-bit / 1M-byte (1,048,576)
256-bytes per programmable page
Uniform 4K-byte Sectors / 64K-byte Blocks

SPI with Single or Dual Outputs
– Clock, Chip Select, Data I/O, Data Out
– Optional Hold function for SPI flexibility

Data Transfer up to 150M-bits / second
– Clock operation to 75MHz
– Fast Read Dual Output instruction
– Auto-increment Read capability

Flexible Architecture with 4KB sectors
– Sector Erase (4K-bytes)
– Block Erase (64K-byte)
– Page program up to 256 bytes <2ms
- Up to 100,000 erase/write cycles
– 20-year retention
Pukao Hats Cleaning Services Ltd.

User avatar
Pito
Posts: 1592
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: STM32F103ZET6 support

Post by Pito » Thu Nov 24, 2016 10:56 pm

Another interesting improvement with ADC:
The 144package has got +Vref and -Vref pins. On that board there are 2 simple LC low pass filters wired on both (bottom side).
Improvement:
To replace the L in the +Vref rail with say 1k resistor, and something like LM136-2.5 voltage reference from +Vref against the ground (or against the -Vref ??) :geek:
Pukao Hats Cleaning Services Ltd.

User avatar
Pito
Posts: 1592
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: STM32F103ZET6 support

Post by Pito » Thu Dec 15, 2016 12:59 pm

Got the http://wiki.stm32duino.com/index.php?ti ... 32F103ZET6 board, flashed the generic_boot20_pc13 bootloader into it, and it seems it works.
Getting this error after the upload:

Code: Select all

maple_loader v0.1
Resetting to bootloader via DTR pulse
Reset via USB Serial Failed! Did you select the right serial port?
Searching for DFU device [1EAF:0003]...
Assuming the board is in perpetual bootloader mode and continuing to attempt dfu programming...

Found it!

Opening USB Device 0x1eaf:0x0003...
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=2, name="STM32duino bootloader v1.0  Upload to Flash 0x8002000"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0800
bytes_per_hash=342
Starting download: [##################################################] finished!
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
error resetting after download: usb_reset: could not reset device, win error: The device is not connected.
The board does not have the usb_disc, so the button needs to be pressed in order to upload.
The resistor on D+ is 4k7 and the SPI flash is the W25X40 here.

A simple ram test:

Code: Select all

// A simple RAM test for the STM32F103ZET board
// Pito 12/2016
int i;
// internal RAM size to test
const uint N = 61000;
uint8_t ram[N];

void setup() {
  // put your setup code here, to run once:
delay(3000);
Serial.begin(115200);
// write some data into the RAM
randomSeed(8878);
Serial.println("Start RAM test");
int elapsed = micros();
for (i=0;i<N;i++) {
  ram[i] = random(255);
}

// You may Inject an Error here or comment it out
ram[33333] = 33; 

// read the RAM back and compare
randomSeed(8878);
for (i=0;i<N;i++) {
  int d = random(255);
  if (ram[i] != d) {
    Serial.print(i);Serial.print(" ram loc is ");Serial.print(ram[i]);
    Serial.print(" but it has to be ");Serial.println(d);
  } 
}
elapsed = micros() - elapsed;
Serial.print("Finished in ");Serial.print(elapsed);Serial.println(" usecs");
}

void loop() {
  // put your main code here, to run repeatedly:
}

// Sketch uses 17,164 bytes (3%) of program storage space. Maximum is 524,288 bytes.
// Global variables use 64,344 bytes of dynamic memory.

// Start RAM test
// 33333 ram loc is 33 but it has to be 27
// Finished in 198559 usecs
Pukao Hats Cleaning Services Ltd.

User avatar
RogerClark
Posts: 7134
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: STM32F103ZET6 support

Post by RogerClark » Thu Dec 15, 2016 7:16 pm

Ignore the usb dfu reset message. It is a biproduct of the way dfu works.

User avatar
Pito
Posts: 1592
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: STM32F103ZET6 support

Post by Pito » Thu Dec 15, 2016 7:25 pm

I do :), thanks.
Btw, I've been always confused by the info on the available flash - why we see the figures for the _total_ flash_on_the_chip when the bootloader eats a bit of it ? :)

Code: Select all

// Sketch uses 17,164 bytes (3%) of program storage space. Maximum is 524,288 bytes.
The same with other boards too..
Pukao Hats Cleaning Services Ltd.

victor_pv
Posts: 1679
Joined: Mon Apr 27, 2015 12:12 pm

Re: STM32F103ZET6 support

Post by victor_pv » Mon Jan 02, 2017 2:56 am

Pito wrote:I do :), thanks.
Btw, I've been always confused by the info on the available flash - why we see the figures for the _total_ flash_on_the_chip when the bootloader eats a bit of it ? :)

Code: Select all

// Sketch uses 17,164 bytes (3%) of program storage space. Maximum is 524,288 bytes.
The same with other boards too..
The bootloader only uses the RAM while it is running, (so uploading something to flash) once it finishes uploading, the RAM that was used for the bootloader can be reused by the main program with no ill effects.
The bootloader will only run again after a reset, at which point the ram will be initialized, so there is no reason to reserve memory for it.

In the old leaflabs linker scripts RAM was being reserved for some reasons, I believe one was that the old bootloader allowed to upload a program to RAM, so to avoid the bootloader overwriting it's own memory while still uploading a program to RAM. I believe there were some other reasons, related to how the first bootloader managed the usb serial, a bit long to explain and honestly I dont remember all the details, but when we started working on the stm32duino bootloader we decided upload to ram with 20K made little sense, so that option was removed. Between that and some other optimizations we also reduced the bootloader size to leave more flash available for the sketch. There are a few old threads with those discussions and tests we made, probably in the General forum.

EDIT: Sorry, I just noticed you were talking about flash. I will leave the explanation above in case help clarify anyone doubts. Regarding the flash, Arduino calculates the total flash available thru some parameter in the boards file or one other of the text files, don't remember of the top of my head which one, but in the past, and probably still, some boards may have that value wrong in that config file.
For boards with bootloader upload option, the flash size should be reduced, I believe the latest bootloader size was under 8K, so that much should not be available for the sketch.
If you select a board option for stlink upload, then all flash is available for the sketch.

Post Reply