TODOPIC
Otros Microcontroladores / Dispositivos programables => Microcontroladores ARM => Mensaje iniciado por: planeta9999 en 21 de Febrero de 2015, 18:23:57
-
Voy a intentar pegar el salto a ARM con STM32, para mis próximos diseños comerciales. Lo primero que necesito, igual que hice con PIC32, es disponer de un bootloader encriptado, imprescindible para poder facilitar actualizaciones del producto, con archivos colgados en internet.
Me decanto, igual que hice con PIC32, por usar tarjetas micro SD, porque tienen una doble función, actualización del firmware y uso como almacenamiento FAT32 con tarjetas de hasta 32GB.
Con PIC32 partí de los fuentes de la nota aplicativa AN1388, tuve que incluir las rutinas de desencriptación XTEA, y desarrollar un programa en el PC con Visual Studio, para encriptar los HEX.
El programa para el PC, me sirve, no lo tengo que volver a hacer, ahora me toca hacer el programa para el STM32, he buscado a ver si encontraba algo prefabricado, aunque fuera un bootloader simple sin encriptar, y no he encontrado NADA. Parece que como los STM32 incluyen por hardware un bootloader, nadie se ha preocupado de desarrollarlo por software, el problema es que ese bootloader no está encriptado, por lo que su utilidad es NULA. Alguien podrá pensar que un bootloader por hardware es útil, ya que te ahorra el programador, el problema es que si vas a hacer tus propios programas, seguro que necesitarás hacer DEBUG, y usando un bootloader eso será imposible, asi que al final, si o si, necesitas un programador que además permita hacer DEBUG, en los PIC puede ser el Pickit 3 y en los ARM STM32 el STLink V2, que en la Discovery ya va integrado.
Así que me toca empezar casi de cero, a construir el programa para el STM32. Como la filosofía de un bootloader ya me la conozco bastante bien, de cuando lo hice para los PIC32, voy a tiro hecho en cuanto a saber que rutinas/librerías concretas necesito, y estas son las siguientes:
1.- Lectura/escritura de tarjetas SD
2.- Desbloqueo de flash
3.- Bloqueo de flash
4.- Saltar a aplicación de usuario
5.- Borrado de memoria flash
6.- Escritura de memoria flash
7.- Rutinas de desencriptación XTEA (ya las tengo hechas para PIC32, me valen sin cambios)
Y estos son los enlaces que he localizado por internet, con la información que necesito para las rutinas/librerias:
1.- Bootloader USB para SMT32F4xx (https://github.com/gbulmer/openstm32sw)
2.- STM32 Escritura/Borrado de Flash (parte-1) (http://chipspace.ru/stm32-flash-program-erase/) (aplicar el traductor de Chrome)
3.- STM32 Escritura/Borrado de Flash (parte-2) (http://we.easyelectronics.ru/STM32/programmirovanie-flash.html) (aplicar el traductor de Chrome)
4.- Bootloader SD Card para STM32F107 (https://github.com/mabl/ARMCM3-STM32F107-BOOTLOADER)
5.- Rutinas en C, Escritura/Borrado de Flash (https://code.google.com/p/stm32f4-discovery-freertos/source/browse/Drivers/ST/STM32F4xx_StdPeriph_Driver/src/stm32f4xx_flash.c?r=f292ed54da1e328fd129e87bf8dbb73a5b150783)
6.- Rutinas Periféricos en C para STM32F4xx (https://code.google.com/p/stm32f4-discovery-freertos/source/browse/Drivers/ST/STM32F4xx_StdPeriph_Driver/src/?r=f292ed54da1e328fd129e87bf8dbb73a5b150783)
7.- Librería FATFS tarjetas SD (http://stm32f4-discovery.com/2014/07/library-21-read-sd-card-fatfs-stm32f4xx-devices/)
8.- Tarjetas SD, FAT STM32F4 (parte 1) (http://thehackerworkshop.com/?p=1103)
9.- Tarjetas SD, FAT STM32F4 (parte 2) (http://thehackerworkshop.com/?p=1161)
10.- Almacenamiento de datos en Flash (http://www.programering.com/a/MjMxQTMwATg.html)
El entorno de desarrollo va a ser Eclipse con el compilador de C++ GCC, todo gratuito, tal como lo documenté en este post, hace tiempo:
http://www.todopic.com.ar/foros/index.php?topic=41267.0
El hardware de pruebas será una tarjeta Discovery con un microcontrolador ARM STM32F407
(http://www.emb4fun.de/archive/stlink/images/stm32f4discovery.jpg)
El borrado de la flash se debe de hacer por SECTORES completos, no se puede borrar solo una dirección, esto es igual que con los PIC, solo que aquí los sectores (páginas en PIC32) son de longitud variable, mientras que con los PIC32 todas las páginas son de 4K. Al igual que con los PIC, antes de escribir en la flash, hay que borrarla, y el borrado es por sectores completos. Esta es la tabla de sectores de la flash de un STM32F4:
(http://www.programering.com/images/remote/ZnJvbT1jaGluYXVuaXgmdXJsPW41R2N1WVRPMEF6TTBFVE9rRlROekVXWjFFV04xTUROelFHTTFNR000QVRZNEVqWnRNRE40SVRNeWtETXZFVE16RURNeThpTjFZVE8zOHladnhtWXYwMmJqNXladnhtWTBsbWJqNXljbGRXWXRsMkx2b0RjMFJIYQ.jpg)
Sobre el papel, y sin haberlo probado todavía, estas podrían ser la piezas del puzzle a encajar:
Gestión de tarjetas SD (lectura y escritura, en FAT32, con las librerías FATFS):
* project example for FATFS
*/
#include "defines.h"
#include "stm32f4xx.h"
#include "tm_stm32f4_delay.h"
#include "tm_stm32f4_disco.h"
#include "tm_stm32f4_fatfs.h"
#include <stdio.h>
#include <string.h>
int main(void) {
//Fatfs object
FATFS FatFs;
//File object
FIL fil;
//Free and total space
uint32_t total, free;
//Initialize system
SystemInit();
//Initialize delays
TM_DELAY_Init();
//Initialize LEDs
TM_DISCO_LedInit();
//Mount drive
if (f_mount(&FatFs, "", 1) == FR_OK) {
//Mounted OK, turn on RED LED
TM_DISCO_LedOn(LED_RED);
//Try to open file
if (f_open(&fil, "1stfile.txt", FA_OPEN_ALWAYS | FA_READ | FA_WRITE) == FR_OK) {
//File opened, turn off RED and turn on GREEN led
TM_DISCO_LedOn(LED_GREEN);
TM_DISCO_LedOff(LED_RED);
//If we put more than 0 characters (everything OK)
if (f_puts("First string in my file\n", &fil) > 0) {
if (TM_FATFS_DriveSize(&total, &free) == FR_OK) {
//Data for drive size are valid
}
//Turn on both leds
TM_DISCO_LedOn(LED_GREEN | LED_RED);
}
//Close file, don't forget this!
f_close(&fil);
}
//Unmount drive, don't forget this!
f_mount(0, "", 1);
}
while (1) {
}
}
Desbloqueo de flash:
void FLASH_Unlock(void)
{
if((FLASH->CR & FLASH_CR_LOCK) != RESET)
{
/* Authorize the FLASH Registers access */
FLASH->KEYR = FLASH_KEY1;
FLASH->KEYR = FLASH_KEY2;
}
}
Bloqueo de Flash:
void FLASH_Lock(void)
{
/* Set the LOCK Bit to lock the FLASH Registers access */
FLASH->CR |= FLASH_CR_LOCK;
}
Borrado de flash (1 sector):
FLASH_Status FLASH_EraseSector(uint32_t FLASH_Sector, uint8_t VoltageRange)
{
uint32_t tmp_psize = 0x0;
FLASH_Status status = FLASH_COMPLETE;
/* Check the parameters */
assert_param(IS_FLASH_SECTOR(FLASH_Sector));
assert_param(IS_VOLTAGERANGE(VoltageRange));
if(VoltageRange == VoltageRange_1)
{
tmp_psize = FLASH_PSIZE_BYTE;
}
else if(VoltageRange == VoltageRange_2)
{
tmp_psize = FLASH_PSIZE_HALF_WORD;
}
else if(VoltageRange == VoltageRange_3)
{
tmp_psize = FLASH_PSIZE_WORD;
}
else
{
tmp_psize = FLASH_PSIZE_DOUBLE_WORD;
}
/* Wait for last operation to be completed */
status = FLASH_WaitForLastOperation();
if(status == FLASH_COMPLETE)
{
/* if the previous operation is completed, proceed to erase the sector */
FLASH->CR &= CR_PSIZE_MASK;
FLASH->CR |= tmp_psize;
FLASH->CR &= SECTOR_MASK;
FLASH->CR |= FLASH_CR_SER | FLASH_Sector;
FLASH->CR |= FLASH_CR_STRT;
/* Wait for last operation to be completed */
status = FLASH_WaitForLastOperation();
/* if the erase operation is completed, disable the SER Bit */
FLASH->CR &= (~FLASH_CR_SER);
FLASH->CR &= SECTOR_MASK;
}
/* Return the Erase Status */
return status;
}
Borrado de flash (completa)
FLASH_Status FLASH_EraseAllSectors(uint8_t VoltageRange)
{
uint32_t tmp_psize = 0x0;
FLASH_Status status = FLASH_COMPLETE;
/* Wait for last operation to be completed */
status = FLASH_WaitForLastOperation();
assert_param(IS_VOLTAGERANGE(VoltageRange));
if(VoltageRange == VoltageRange_1)
{
tmp_psize = FLASH_PSIZE_BYTE;
}
else if(VoltageRange == VoltageRange_2)
{
tmp_psize = FLASH_PSIZE_HALF_WORD;
}
else if(VoltageRange == VoltageRange_3)
{
tmp_psize = FLASH_PSIZE_WORD;
}
else
{
tmp_psize = FLASH_PSIZE_DOUBLE_WORD;
}
if(status == FLASH_COMPLETE)
{
/* if the previous operation is completed, proceed to erase all sectors */
FLASH->CR &= CR_PSIZE_MASK;
FLASH->CR |= tmp_psize;
FLASH->CR |= FLASH_CR_MER;
FLASH->CR |= FLASH_CR_STRT;
/* Wait for last operation to be completed */
status = FLASH_WaitForLastOperation();
/* if the erase operation is completed, disable the MER Bit */
FLASH->CR &= (~FLASH_CR_MER);
}
/* Return the Erase Status */
return status;
}
Escritura en flash (32 bit)
FLASH_Status FLASH_ProgramWord(uint32_t Address, uint32_t Data)
{
FLASH_Status status = FLASH_COMPLETE;
/* Check the parameters */
assert_param(IS_FLASH_ADDRESS(Address));
/* Wait for last operation to be completed */
status = FLASH_WaitForLastOperation();
if(status == FLASH_COMPLETE)
{
/* if the previous operation is completed, proceed to program the new data */
FLASH->CR &= CR_PSIZE_MASK;
FLASH->CR |= FLASH_PSIZE_WORD;
FLASH->CR |= FLASH_CR_PG;
*(__IO uint32_t*)Address = Data;
/* Wait for last operation to be completed */
status = FLASH_WaitForLastOperation();
/* if the program operation is completed, disable the PG Bit */
FLASH->CR &= (~FLASH_CR_PG);
}
/* Return the Program Status */
return status;
}
Un ejemplo completo de borrado/escritura de Flash en un STM32F1xx
#include "stm32f10x.h"
#define FLASH_KEY1 ((uint32_t)0x45670123)
#define FLASH_KEY2 ((uint32_t)0xCDEF89AB)
#define Page_127 0x0801FC00
uint16_t i;
int main()
{
//FLASH_Unlock
FLASH->KEYR = FLASH_KEY1;
FLASH->KEYR = FLASH_KEY2;
//FLASH_Erase Page
while((FLASH->SR&FLASH_SR_BSY));
FLASH->CR |= FLASH_CR_PER; //Page Erase Set
FLASH->AR = Page_127; //Page Address
FLASH->CR |= FLASH_CR_STRT; //Start Page Erase
while((FLASH->SR&FLASH_SR_BSY));
FLASH->CR &= ~FLASH_CR_PER; //Page Erase Clear
//FLASH_Program HalfWord
FLASH->CR |= FLASH_CR_PG;
for(i=0; i<1024; i+=2)
{
while((FLASH->SR&FLASH_SR_BSY));
*(__IO uint16_t*)(Page_127 + i) = i;
}
FLASH->CR &= ~FLASH_CR_PG;
FLASH->CR |= FLASH_CR_LOCK;
while(1);
}
}
Saltar a aplicación de usuario
void jumpToUser (u32 usrAddr) {
typedef void (*funcPtr)(void);
u32 jumpAddr = *(vu32*) (usrAddr + 0x04); /* reset ptr in vector table */
funcPtr usrMain = (funcPtr) jumpAddr;
/* tear down all the dfu related setup */
// disable usb interrupts, clear them, turn off usb, set the disc pin
// todo pick exactly what we want to do here, now its just a conservative
#ifdef STM32F2
nvicDisableInterrupts();
#else
flashLock();
usbDsbISR();
nvicDisableInterrupts();
usbDsbBus();
#endif
systemReset(); // resets clocks and periphs, not core regs
__MSR_MSP(*(vu32*) usrAddr); /* set the users stack ptr */
setPin(LED_BANK,LED);
usrMain(); /* go! */
}
-
Muy bueno amigo, ahora mismo estoy metido en un diseño hardware muy complejo con un stm32f439 y precisamente un bootloader encriptado es lo primero k va a llevar y ademas por microsd y para mas casualidades, yo también tengo el mio en pic pero por usb msd para pendrive, k es mas o menos lo mismo, y ahora voy a migrar mas seriamente a ARM, así k seguiré tu trabajo con atencion, por cierto estas teniendo problemas con encontrar informacion y librerias? Es la única pega k le pongo a st k podría tener mejor documentación.
Un saludo y buen trabajo tiene buena pinta
-
Me suscribo al hilo, muy interesante.
-
por cierto estas teniendo problemas con encontrar informacion y librerias? Es la única pega k le pongo a st k podría tener mejor documentación.
Si, comparado con Microchip, se echa en falta más aplicaciones de ejemplo, algo como las antiguas Application Libraries de Microchip, ahora HArmony.
En ST tienes STM32CubeMx, un generador bastante cutre, que solo genera código fuente para EWARM, MDK o TruSTUDIO. Que mala visión de mercado tienen los de ST, no ser conscientes de que para superar a la competencia es importante ofrecer herramientas de trabajo GRATUITAS, no entiendo porque no facilitan las cosas para trabajar con Eclipse, Coocox o EmBlocks, y que puñetero cariño le han cogido a Keil, como si todos nos pudieramos gastar alegremente 4000 euros. Lo único que te dan son las CMSIS, con los archivos .H que definen los registros de los periféricos, pero no hay aplicaciones completas de ejemplo.
He estado mirando el tema de los IDE gratuitos, y he encontrado otro muy interesante, EmBlocks, basado en Codeblocks, con un aspecto muy similar a Visual Studio: http://www.emblocks.org/web/ Hay que probarlo, he leido algunas opiniones por internet, y bastante gente lo prefiere a Coocox. Me he instalado la última versión de Coocox y no está nada mal, aunque su generador de código CoSmart se ha quedado en nada, ni siquiera soporta los micros de ST.
Resumiendo, hay 3 entornos de desarrollo gratuitos, todos basados en el compilador de C/C++ GCC:
1.- Eclipse + GCC Eclipse (https://eclipse.org/downloads/) Versión LUNA actualizado a Enero de 2015 GCC (https://launchpad.net/gcc-arm-embedded) Versión 4.9 a Diciembre de 2014
2.- Coocox + GCC (basado en Eclipse) http://www.coocox.org/ Versión 1.7.8 actualizado a Febrero de 2015
3.- EmBlocks + GCC (basado en CodeBlocks) http://www.emblocks.org/web/ Versión 2.30 actualizado a Octubre de 2014
Aunque Eclipse permite un control total, la verdad es que es complicado de configurar y mantener, mientras que los otros dos se instalan y a funcionar de inmediato, seleccionas el chip y el IDE te lo configura todo. Tanto Coocox como Emblocks están actualizados para soportar hasta los últimos STM32, que creo son los F439, y también soportan micros ARM de otros fabricantes. Además trabajando con Coocox, como está basado en Eclipse, el proyecto se puede traspasar sin problemas a Eclipse si fuera necesario.
Voy a probar los tres, con las últimas versiones, a ver por cual me decanto, de momento me atrae bastante EmBlocks, la mayoría de gente que ha probado Coocox y EmBlocks, opina que el segundo es mucho más rápido.
Como curiosidad, EmBlocks, también soporta los PIC32, aunque yo para los PIC prefiero MPLAB y MPLABX.
Y otra curiosidad, EmBlocks permite importar proyectos hechos en Coocox y MPLABX.
Un apunte más, parece que hay un PLugin para usar el generador de código STM32Cubemx en Eclipse, habrá que probarlo:
http://www.st.com/web/en/catalog/tools/PF257931
-
Cierto, es lo que me gusta de microchip, que tendrá todos sus defectos, pero facilita mucho el trabajo, los basados en ARM sin embargo veo que los entornos de desarrollo son caros y en la mayoría de los casos ni siquiera son propios, solo algunos como TI ofrece su "code composer estudio" o ccs, y una buena herramienta para generar código, al estilo harmony (pero de gratis nada, caro de narices), la mayoría, KEIL, IAR etc, los de ST han hecho muy bien su trabajo en el tema hardware ofreciendo placas de desarrollo y programadoras muy baratas, pero pfff... no se que es peor.
de todas maneras en los de microchip he ido apreciando que cada vez son mas limitados sus compiladores free, y hay algunas cosas que no puedes hacer con ellos, es mas los pic32mx1xx y 2xx de 16kb de memoria son practicamente inutiles ya que no cabe ningún programa, puedes cambiar estados de los pines y tal y no pongas mas de 8 funciones en tu código xk vas a tener problemas.
coocox es muy buena herramienta cuando salio me alegre mucho, pero hasta que soportáron los 439 paso bastante tiempo, lo que quiere decir que si quieres trabajar con lo ultimo de lo ultimo tendrás que esperar.
y también lo que comentas los pocos ejemplos que hay, para las discovery por ejemplo son para keil IAR etc pero de coocox o eclipse nada de nada.
el de EmBlocks no lo conocía, no olvides dar tu opinión cuando lo pruebes.
un saludo.
-
Este libro parece interesante para entrar en materia, incluso tiene algún capítulo dedicado a Coocox, está en papel y en PDF. Editado a finales de 2013, 864 páginas, en Amazon lo ponen muy bien. En un ratito, creo que podré ojear la versión en PDF.
(http://cv01.twirpx.net/1451/1451220.jpg)
-
desde luego el titulo promete, espero que sirva de ayuda.
-
Cierto, es lo que me gusta de microchip, que tendrá todos sus defectos, pero facilita mucho el trabajo, los basados en ARM sin embargo veo que los entornos de desarrollo son caros y en la mayoría de los casos ni siquiera son propios, solo algunos como TI ofrece su "code composer estudio" o ccs, y una buena herramienta para generar código, al estilo harmony (pero de gratis nada, caro de narices), la mayoría, KEIL, IAR etc, los de ST han hecho muy bien su trabajo en el tema hardware ofreciendo placas de desarrollo y programadoras muy baratas, pero pfff... no se que es peor.
de todas maneras en los de microchip he ido apreciando que cada vez son mas limitados sus compiladores free, y hay algunas cosas que no puedes hacer con ellos, es mas los pic32mx1xx y 2xx de 16kb de memoria son practicamente inutiles ya que no cabe ningún programa, puedes cambiar estados de los pines y tal y no pongas mas de 8 funciones en tu código xk vas a tener problemas.
Hay una alternativa de pago, bastante asequible, pero no se que calidad tendrán estos compiladores, me refiero a los de Mikroelektronica. Tienen compiladores tanto para PIC como para ARM, de C, Basic y Pascal, y muy baratitos en comparación con otros.
http://www.mikroe.com/mikroc/arm/
Yo hace años distribuí en España los productos de Mikroe, los entrenadores estaban muy bien, de los compiladores aunque vendí alguno de C, nunca los probé.
-
Añado más información interesante para hacer el bootloader.
Algo de esto leí hace tiempo, y hoy lo he confirmado, con otra información adicional que desconocía.
Los STM32, tienen una característica muy interesante, que no tienen los PIC32, y es que cada chip incluye de fábrica un Código de Identificación UNICO, de 96 bits, además de otros 3 identificadores, todos ellos grabados de fábrica, y solo se pueden leer, no se pueden modificar.
Estos 4 identificadores son los siguientes:
1.- Firma de dispositivo: 16 bit, identifica el tipo de chip.
0x0413: STM32F405xx/07xx and STM32F415xx/17xx)
0x0419: STM32F42xxx and STM32F43xxx
0x0423: STM32F401xB/C
0x0433: STM32F401xD/E
0x0431: STM32F411xC/E
2.- Revisión de dispositivo:
0x1000: Revision A
0x1001: Revision Z
0x1003: Revision Y
0x1007: Revision 1
0x2001: Revision 3
3.- Tamaño de flash: 16 bit, valor en Kb.
4.- Identificador de dispositivo único: 96 bit, se trata de un código programado de fábrica, único por chip.
En mi booloader para PIC32, grabo un código único por chip, para poder tracear en todo momento cada placa, así se pueden identificar posibles placas pirateadas, para bloquearlas con las siguientes actualizaciones de firmware. Ese código lo grabo en la flash en el momento de inicializar el bootloader en cada placa. En los STM32, ese código único por chip, ya viene grabado de fábrica en cada chip, así que eso que nos ahorramos. También se puede utilizar el código único, para crear actualizaciones personalizadas para un cliente, de manera que solo se pueda instalar en esa placa, limitar que firmware de producto se puede instalar en esa placa por nº de serie único, firma de dispositivo y revisión, etc...
Ejemplo de código fuente para leer los 4 identificadores:
/**
* Identification library for STM32F4
*
* This library allows you to read following things:
* - Device's 96bit unique ID
* - Device signature
* - Revision
* - Flash size
*
* Revisions possible:
* - 0x1000: Revision A
* - 0x1001: Revision Z
* - 0x1003: Revision Y
* - 0x1007: Revision 1
* - 0x2001: Revision 3
*
* Device signatures:
* - 0x0413: STM32F405xx/07xx and STM32F415xx/17xx)
* - 0x0419: STM32F42xxx and STM32F43xxx
* - 0x0423: STM32F401xB/C
* - 0x0433: STM32F401xD/E
* - 0x0431: STM32F411xC/E
*
* Flash size:
* - Device has stored value of flash size in kB
*/
#ifndef TM_IDENTIFICATION_H
#define TM_IDENTIFICATION_H 100
/* C++ detection */
#ifdef __cplusplus
extern C {
#endif
/**
* Library dependencies
* - STM32F4xx
*/
/**
* Includes
*/
#include "stm32f4xx.h"
/* Addresses in device */
#define ID_UNIQUE_ADDRESS 0x1FFF7A10
#define ID_FLASH_ADDRESS 0x1FFF7A22
#define ID_DBGMCU_IDCODE 0xE0042000
/**
* With this "function" you are able to get signature of device.
*
* Possible returns:
* - 0x0413: STM32F405xx/07xx and STM32F415xx/17xx)
* - 0x0419: STM32F42xxx and STM32F43xxx
* - 0x0423: STM32F401xB/C
* - 0x0433: STM32F401xD/E
* - 0x0431: STM32F411xC/E
*
* Returned data is in 16-bit mode, but only bits 11:0 are valid, bits 15:12 are always 0.
* Defined as macro
*/
#define TM_ID_GetSignature() ((*(uint16_t *) (ID_DBGMCU_IDCODE)) & 0x0FFF)
/**
* With this "function" you are able to get revision of device.
*
* Revisions possible:
* - 0x1000: Revision A
* - 0x1001: Revision Z
* - 0x1003: Revision Y
* - 0x1007: Revision 1
* - 0x2001: Revision 3
*
* Returned data is in 16-bit mode.
* Defined as macro
*/
#define TM_ID_GetRevision() (*(uint16_t *) (ID_DBGMCU_IDCODE + 2))
/**
* With this "function" you are able to get flash size of device.
*
* Returned data is in 16-bit mode, returned value is flash size in kB (kilo bytes).
* Defined as macro
*/
#define TM_ID_GetFlashSize() (*(uint16_t *) (ID_FLASH_ADDRESS))
/**
* With this "function" you are able to get unique ID of device in 8-bit (byte) read mode.
* Unique ID is 96bit long, but if you need just some parts of it, you can read them with 8bit function.
*
* Parameters:
* - uint8_t x:
* Value between 0 and 11, corresponding to byte you want to read from 96bits (12bytes)
*
* Returned data is 8-bit
* Defined as macro
*/
#define TM_ID_GetUnique8(x) ((x >= 0 && x < 12) ? (*(uint8_t *) (ID_UNIQUE_ADDRESS + (x))) : 0)
/**
* With this "function" you are able to get unique ID of device in 16-bit (byte) read mode.
* Unique ID is 96bit long, but if you need just some parts of it, you can read them with 16bit function.
*
* Parameters:
* - uint8_t x:
* Value between 0 and 5, corresponding to 2-bytes you want to read from 96bits (12bytes)
*
* Returned data is 16-bit
* Defined as macro
*/
#define TM_ID_GetUnique16(x) ((x >= 0 && x < 6) ? (*(uint16_t *) (ID_UNIQUE_ADDRESS + 2 * (x))) : 0)
/**
* With this "function" you are able to get unique ID of device in 32-bit (byte) read mode.
* Unique ID is 96bit long, but if you need just some parts of it, you can read them with 32bit function.
*
* Parameters:
* - uint8_t x:
* Value between 0 and 2, corresponding to 4-bytes you want to read from 96bits (12bytes)
*
* Returned data is 32-bit
* Defined as macro
*/
#define TM_ID_GetUnique32(x) ((x >= 0 && x < 3) ? (*(uint32_t *) (ID_UNIQUE_ADDRESS + 4 * (x))) : 0)
/* C++ detection */
#ifdef __cplusplus
}
#endif
#endif
-
Es muy util para identificar individualmente los dispositivos que fabricas, pero ten cuidado, es un arma de doble filo, esto también te obliga a tener una base de datos que sera bastante extensa si vendes mucho y un error en esa base de datos, puede que el bootloader se quede inservible para ese cliente.
pero como tu dices, esto es fantastico para que no te llegue un "chino", por llamarlo de alguna manera, te copie el hardware y meta tu código.
los pic si tienen, hasta donde llegan mis conocimientos como mínimo la revisión del dispositivo, lo que no se si es adcesible de alguna manera
buen trabajo amigo, estoy aprendiendo mucho gracias a ti.
-
Es muy util para identificar individualmente los dispositivos que fabricas, pero ten cuidado, es un arma de doble filo, esto también te obliga a tener una base de datos que sera bastante extensa si vendes mucho y un error en esa base de datos, puede que el bootloader se quede inservible para ese cliente.
La anulación de una placa pirateada es una de las utilidades, yo eso lo he visto aplicado en productos comerciales, y ha sido muy efectivo para tirar producto chino pirateado, en concreto interfaces de diagnosis para automoción, el fabricante crea una lista negra de números de serie, la mete en la siguiente actualización, y en cuanto la aplican las placas piratas, caen como chinches. Ten en cuenta que una lista negra no suele ser muy extensa, se trata de uno o varios números de serie, utilizados en cientos o miles de placas, todas con el mismo número de serie.
También se puede usar para personalizar un producto, para un cliente concreto que compre una mejora o encargue un diseño específico. En mi bootloader para PIC32 grabo otros dos códigos, uno por tipo de producto y otro por versión, para evitar que por error o deliberadamente se instalen ficheros de firmware de otro producto, o para evitar que se instalen versiones anteriores. Si el nº de serie de una placa está en la lista negra, puedo marcar una dirección en flash para impedir que vuelva a arrancar, o puedo incluso borrar el bootloader para dejar inservible la placa.
los pic si tienen, hasta donde llegan mis conocimientos como mínimo la revisión del dispositivo, lo que no se si es adcesible de alguna manera
No he utilizado nunca ese código, porque no permitiría bloquear una placa concreta, ni crear personalizaciones, pero bueno es saberlo, alguna utilidad se me ocurrirá.
Sobre los IDE, ayer estuve probando Coocox y EmBlocks, pude confirmar algo que ya comprobé hace tiempo, y descubrí algo nuevo. De momento todo está a favor de EmBlocks, y en contra de Coocox.
1.- Ya hace tiempo hubo una cosa que no me gustó nada de Coocox, y sigue igual, no lo han corregido, y eso que hay más gente quejándose de lo mismo en sus foros. Coocox NO permite IMPORTAR directorios o árboles de directorios con sus correspondiente archivos, al proyecto. Si quieres añadir un conjunto de directorios y subdirectiorios con sus archivos de librerías, fuentes en C y archivos H, tienes que crear A MANO los directorios y subdirectorios y subir a mano uno a uno cada archivo. Osea que NO existe algo como "Importar directorio" al proyecto, alucinante. Responde la gente de Coocox a estas quejas, diciendo que se puede usar el "Drag and Drop", pero eso no importa nada, simplemente crea un vínculo a los directorios, de manera que si cambias esos directorios, o mueves el proyecto a otro ordenador, te da error, por perder los vínculos a los directorios originales. Todo esto no ocurre con EmBlocks, Si que tiene una opción para IMPORTAR directorios completos con sus subdirectorios y archivos contenidos, así que punto a favor de Emblocks.
2.- La apertura de un proyecto en Coocox, es extremadamente LENTA, muy molesta, y eso aunque sea un mísero proyecto de los más simples, como un programa para endender y apagar un LED. También hay gente que ha reportado este problema en los foros de Coocox, parece que es debido a la lectura de la base de datos SQLite3 por parte de la DLL ICoodat.dll, cuando se abre un proyecto, dicén que lo resolverán, pero es un problema que ya anda coleando desde hace tiempo. Con EmBlocks no he notado este problema, los proyectos se abren con relativa rapidez.
3.- EmBlocks permite añadir en TOOLS, botones personalizados para llamar a aplicaciones externas, interesante para por ejemplo, crear un botón que llamé al software para programar el chip, en el caso de los STM32 para llamar al programa STM32-STLINK Utility de ST. Esto se puede hacer también en Eclipse, como ya documenté, pero NO se puede hacer en Coocox. Coocox facilita un programa propio (CoFlash), inpendiente del IDE para programar los chips, pero para eso mejor usar el de ST. Otro punto a favor de EmBlocks.
Así que creo que me decantaré por EmBlocks, como ya comenté además permite importar proyectos de Coocox y MPLABX, y se trata de un IDE muy similar a Visual Studio, es casí un calco. Para los que hemos trabajado con VC++ nos resultará muy familiar.
En breve empezaré con las primeras pruebas, que serán crear las rutinas de lectura, modificación y escritura en tarjetas SD, luego las rutinas de borrado-escritura de flash, y finalmente encajarlo todo para que se lea y grabe el nuevo firmware. Veo que la filosofía del Link Scripter, es igual que con los PIC32, importante para compilar el firmware, creo que parte de las rutinas que usé para el PIC32, las podré usar para los STM32, cambiando solo las instrucciones concretas que borran y escriben en la Flash, me ahorrará bastante trabajo, es lo bueno que tiene el C, la portabilidad.
-
He localizado otro IDE más gratuito, se llama emIDE y al igual que EmBlocks, también está basado en CodeBlocks y GCC.
http://www.emide.org/index.html
Nació en Abril de 2013, y se actualizó por última vez en Mayo de 2014, con soporte para todos los STM32 hasta el F439. El asistente para crear proyectos nuevos, no es tan completo como el de EmBlocks.
Por las visitas a su foro, no parece que tenga mucha clientela, prefiero seguir con EmBlocks, aunque no hay que perder de vista a este IDE, si cumplen con las mejoras futuras que anuncian, como la posibilidad de importar proyectos de IAR/uvision o poder usar el compilador de KEIL.
Y sobre EmBlocks, he hecho un feliz descubrimiento, permite abrir proyectos creados con Keil uvision, que por suerte o por desgracia son la mayoría de los ejemplos que proporciona ST.
-
Y sobre EmBlocks, he hecho un feliz descubrimiento, permite abrir proyectos creados con Keil uvision, que por suerte o por desgracia son la mayoría de los ejemplos que proporciona ST.
ufff notición, entonces los de Emblocks han pasado por la derecha a los de coocox, ¿has probado a compilar? ¿parece muy bonito para ser cierto xd quizas se importa pero luego da muchos errores?
si la ultima actualización es de mayo de 2014 parece que el proyecto emIDE esta un poco olvidado.
lo que has comentado de anular las placas piratas me parece muy buena idea, piratear al pirata, lo tendré muy en cuenta.
-
Preparando el material para las primeras pruebas.
Tarjeta Discovery con un STM32F407, placa base de Waveshare y tarjetero micro SD.
(http://i1121.photobucket.com/albums/l518/xmen4001/discovery_001_zpsim4cjwn6.jpg)
El conjunto ensamblado:
(http://i1121.photobucket.com/albums/l518/xmen4001/discovery_003_zpsbcp6pnl6.jpg)
Aprovecharé para probar unas cuantas de las tarjetas que venían con el kit, un par de decodificadores MP3, tarjeta USB a serie virtual, USB Host OTG, teclados directos y en matriz, display BCD y un amplificador de BF. Todas se pueden conectar a la placa de Waveshare, y de ahí a la Discovery.
(http://i1121.photobucket.com/albums/l518/xmen4001/discovery_002_zpsqtthfro1.jpg)
-
ufff notición, entonces los de Emblocks han pasado por la derecha a los de coocox, ¿has probado a compilar? ¿parece muy bonito para ser cierto xd quizas se importa pero luego da muchos errores?
No he probado todavía a compilar proyectos de Keil en EmBlocks, no se como quedará la cosa. El problema es que Keil me parece que no usa GCC, entonces podrían haber algunas diferencias de nomenclatura en el C de ambos productos, aparte de configurar bien los path para que el compilador localice todos los archivos, hay que probarlo.
-
The Keil MDK-ARM can be used with the GNU Compiler Collection (GCC). GCC is an open-source development effort with numerous contributors, it is widely available and supports many devices.
http://www.keil.com/arm/gnu.asp
Y la aplicacion para eso:
http://m8051.blogspot.com.ar/2012/10/using-gcc-in-keil-best-of-both-worlds.html
-
The Keil MDK-ARM can be used with the GNU Compiler Collection (GCC). GCC is an open-source development effort with numerous contributors, it is widely available and supports many devices.
http://www.keil.com/arm/gnu.asp
Y la aplicacion para eso:
http://m8051.blogspot.com.ar/2012/10/using-gcc-in-keil-best-of-both-worlds.html
Eso parece interesante, pero ¿ esa combinación de IDE MDK-ARM de Keil con el compilador GCC, tiene limitaciones ?, porque si sigue limitado a 32K no tiene ninguna utilidad, y lo que me parecería raro es que Keil permita que se use su IDE de manera gratuita, combinándolo con otro compilador también gratuito, como es GCC.
Me acabo de descargar de la web de Keil su última versión, la 5.14, y me deja configurar GCC como compilador, voy a ver si consigo algún proyecto que supere los 32K del objeto compilado, a ver si me deja.
-
Yo imagino que si ya que el articulo que pase al ultimo habla de sobre querer superar el limite de los 32kb y que por eso se encaminaba a Coocox, CCS de TI o el Keil con GCC.
voy a ver si consigo algún proyecto que supere los 32K del objeto compilado, a ver si me deja.
Sino create un proyecto con mucha basura xD, por ejemplo que asigne a un registro un valor y repetilo, sacale las optimizaciones por las dudas que quiera optimizarlo.. es lo unico que se me ocurre.. y si queres algun proyecto medio grande podes buscar los que tiene FreeRTOS se que hay varios ejemplos para ST. Por ejemplo hay un ejemplo que dice:
CORTEX_STM32F107_GCC_Rowley
-
Es un poco raro que Keil permita que se use su IDE de manera gratuita, además la versión lite también tiene limitaciones de 32k con el Debug, y eso ya no creo que esté relacionado con el compilador. Tal vez la limitación esté en el proceso de enlazado, en ese caso dará igual usar GCC, los objetos los crearía GCC sin limites, pero el enlazador no permitiría crear un ejecutable mayor de 32k si no pagas la licencia de uso.
Lo probaré a ver que sale, pero no creo que sea tan sencillo.
MDK-ARM Lite Edition
Programs that generate more than 32 Kbytes of code and data will not compile, assemble, or link.
The debugger supports programs that are 32 Kbytes or smaller.
The compiler does not generate a disassembly listing of the machine code generated. The -S, --asm, and --interleave compiler command-line options are disabled. Projects will not compile with Target -> Listing -> C Compiler Listing enabled.
The compiler and assembler do not generate position-independent code or data. The --apcs /ropi /rwpi /pic/ pid compiler and assembler command line options are disabled.
The assembler and linker create Symbolic Output Format objects which cannot be linked with third-party linker utilities. Fully licensed tools generate standard ELF/DWARF files which may be used with third-party utilities.
The linker does not accept scatter-loading description files for sophisticated memory layouts. The --scatter command line option is disabled.
-
no te ha convencido del todo entonces el Emblock?, de todas formas si se puediera utilizar el keil uvision de manera gratuita, sin ninguna limitación no estaria nada mal, esperando tus pruebas y veredictos
-
por cierto KILLERJC, que de que articulo hablas puedes poner un enlace? me interesa lo del ccs de TI tambien
-
no te ha convencido del todo entonces el Emblock?, de todas formas si se puediera utilizar el keil uvision de manera gratuita, sin ninguna limitación no estaria nada mal, esperando tus pruebas y veredictos
EmBlocks de momento es fantástico, cada vez descubro cosas nuevas de los más interesantes, como la posibilidad de guardar un proyecto como Template, para reutilizarlo en proyectos nuevos, o el potentísimo gestor de Scripts que tiene, el producto es MUY BUENO, definitivamente me quedo con EmBlocks para el desarrollo del Bootloader y proyectos futuros.
No parece que haya problema con abrir y compilar proyectos de Keil en EmBlocks, porque si Keil permite usar GCC en su IDE es porque los fuentes son compatibles con ambos compiladores, así tenemos con Emblocks un producto de lo más versátil, que puede abrir proyectos propios, y tambien importar proyectos creados con Coocox o MDK-ARM de Keil.
Lo que estaba probando es lo que comentó KILLERJC, de usar Keil con GCC, más que nada por curiosidad, porque incluso aunque sea posible, el IDE de EmBlocks no tiene nada que envidiarle al de Keil, es más, creo que lo supera con su gestor de Scripts y Templates.
-
por cierto KILLERJC, que de que articulo hablas puedes poner un enlace? me interesa lo del ccs de TI tambien
Del mismo que puse... el segundo link..
Aunque no esta completo el articulo, lo dejaron como que se iba a hacer pronto pero quedo ahi...
Yo de igual manera espero ver los resultados de planeta sobre le keil y el emblocks. Hasta me gustaria tener una plaquita con un ST :)
-
Lo que estaba probando es lo que comentó KILLERJC, de usar Keil con GCC, más que nada por curiosidad, porque incluso aunque sea posible, el IDE de EmBlocks no tiene nada que envidiarle al de Keil, es más, creo que lo supera con su gestor de Scripts y Templates.
Es mas a mi el keil tampoco es que me guste mucho, no facilita mucho las cosas del programador no chiva nada, y tuve una mala experiencia una vez con el keil uvision 4 y un proyecto con el stm32f407, el compilador se tragaba un fallo de código y hasta que encontre el problema....pufff, era un registro del microcontrolador que esta mal en las definiciones que se incluian en el proyecto.
-
He tenido suerte, con la placa de Waveshare me vino un DVD con un montón de ejemplos, entre ellos un proyecto completo para manejar tarjetas SD FAT/FAT32 con las librerías FATFS. Como es de esperar los proyectos de ejemplos, todos para Keil, pero afortunadamente ya he resuelto como importarlos a Emblocks, sin que den un montón de errores en la compilación, ya documentaré eso más adelante con detalle, porque no basta con usar el menú de importación de Emblocks, si se compila así da un capazo de errores.
Básicamente para importar un proyecto de Keil a Emblocks, hay que crear un proyecto limpio en Emblocks, y desde ahí AÑADIR los directorios del proyecto original que contienen las librerías que nos falten, y el main.c, el resto incluido la definición de los parámetros del compilador, linkador, el linker script (stm32f407vg_flash.ld) y el archivo en asembler (startup_stm32f4xx.S) tienen que ser de un proyecto limpio creado en Emblocks, NO valen los del proyecto de Keil.
En cuanto al IDE a usar, definitivamente Emblocks es el mejor con diferencia.
Dejo otra dirección web MUY interesante, para encontrar librerías para los STM32, hay prácticamente de todo, una maravilla:
http://stm32f4-discovery.com/2014/05/all-stm32f429-libraries-at-one-place/
Y un buen tutorial de Emblocks: http://www.emblocks.org/wiki/
Aquí el proyecto con las librerías FATFS, importado de Keil a Emblocks, para gestionar tarjetas SD con FAT/FAT32, y compilado sin problemas, ahora voy a probarlo sobre la placa. Si todo va bíen paso a la gestión de la memoria Flash, para eso también hay un proyecto en el CD de Waveshare, creo que todo va a ir más rápido de lo que pensaba.
(http://i1121.photobucket.com/albums/l518/xmen4001/STM32_FATFS_emblocks_zpscinmrval.jpg)
-
Excelente. Y que buena suerte la tuya :).
Con respecto a lo que decis si yo pasara del CCS de TI a Eclipse con GCC tambien deberia cambiar todas las definiciones de memoria / startup / vectores, etc.
Pregunta de novato planeta..
En un bootloader basicamente reservas un espacio de memoria flash para el mismo y no tocas esa memoria mientras grabas la otra. imagino que en eso estara el fatfs para manejar la SD etc.
Estoy en lo correcto?
Tambien me encontre que en el micro que tengo de TI (TM4C1294NCPDT) la memoria flash esta "dividida" en 4 bancos asi hay un buffer que toma de a varios bytes ( y usa un LRU ) para seguir la velocidad del micro, puedo borrar de 16kB y escribir 32 palabras de 32bytes a la ves, pero si tengo que escribir en el mismo banco que esta mi bootloader deberia mudar el bootloader a la RAM, y ejecutarla de ahi. Ya que dice que mientras esta grabando se vuelve inacceesible el acceso al banco para otras cosas. Te ocurre algo parecido a vos con el de ST?
Y por ultimo en tu definicion de memoria lo dividis en bootloader y programa a toda la flash o le das una direccion especifica ? por ejemplo definis una seccion llamada bootloader. me explico con el codigo que poseo:
SECTIONS
{
.intvecs: > 0x00000000
.text : > FLASH
.const : > FLASH
.cinit : > FLASH
.pinit : > FLASH
.init_array : > FLASH
// Aca agregaria un .bootloader : > FLASH
.vtable : > 0x20000000
.data : > SRAM
.bss : > SRAM
.sysmem : > SRAM
.stack : > SRAM
}
__STACK_TOP = __stack + 512;
Aunque eso signifique poner algo en ASM :/, o como indicas que se almacene en cierto lugar.. me quede con los ORG 0x00 de los pics :/
-
he entrado para colgar la pagina de las librerias que has colgado tu y me has adelantado xd, la he encontrado esta mañana en el curro.
el CD que supongo que no esta disponible para descargar por internet verdad?, por cierto, no te vendrá un esquematico con la referencia del joystick que te trae la placa whaveshare? estoy buscando uno para mi proyecto pero todos los que encuentro están obsoletos.
-
Pregunta de novato planeta..
En un bootloader basicamente reservas un espacio de memoria flash para el mismo y no tocas esa memoria mientras grabas la otra. imagino que en eso estara el fatfs para manejar la SD etc.
Estoy en lo correcto?
La clave está en el archivo Linker Script con el que compilas el programa, ahí le dices al enlazador en que dirección debe de empezar a colocar el programa. Eso hay que configurarlo cuando compilas el firmware, no cuando compilas el bootloader. Hay que ver cuanto ocupa el bootloader, cual es la última dirección de flash usada, y coger la primera dirección libre de la siguiente página para compilar el firmware.
Por ejemplo en el linker script que estoy usando para hacer el bootloader, el fichero stm32f407vg_flash.ld, nos encontramos entre muchas otras cosas con esto:
/* Memory Spaces Definitions */
MEMORY
{
ROM (rx) : ORIGIN = 0x08000000, LENGTH = 1024K
RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
CCRAM (rwx) : ORIGIN = 0x10000000, LENGTH = 64K
}
El parámetro ROM ORIGIN nos está diciendo la primera dirección de la flash donde el enlazador debe de ubicar el programa, en este caso en la 0x08000000, también le dice al enlazador que el tamaño de la flash es de 1024K. Todo esto no lo tocamos para compilar el bootloader, pero si que habrá que tocarlo para compilar el firmware. Por ejemplo si el bootloader ocupa 40960 bytes, en hexadecimal 0xA000, el firmware tendría que ir al principio de la siguiente página de esa dirección, mirando el mapa de direcciones de la flash, eso sería la dirección 0x0800C000 (Sector o página 3), y el linker script para compilar el firmware quedaría así.
/* Memory Spaces Definitions */
MEMORY
{
ROM (rx) : ORIGIN = 0x0800C000, LENGTH = 1024K
RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
CCRAM (rwx) : ORIGIN = 0x10000000, LENGTH = 64K
}
Bueno, el tamaño de la flash disponible ya no serían 1024K, sino 1024K menos el tamaño del bootloader.
Tambien me encontre que en el micro que tengo de TI (TM4C1294NCPDT) la memoria flash esta "dividida" en 4 bancos asi hay un buffer que toma de a varios bytes ( y usa un LRU ) para seguir la velocidad del micro, puedo borrar de 16kB y escribir 32 palabras de 32bytes a la ves, pero si tengo que escribir en el mismo banco que esta mi bootloader deberia mudar el bootloader a la RAM, y ejecutarla de ahi. Ya que dice que mientras esta grabando se vuelve inacceesible el acceso al banco para otras cosas. Te ocurre algo parecido a vos con el de ST?
En un STM32F407 (1Mega de flash), la flash está dividida en 11 SEctores o páginas, y todos no son del mismo tamaño. Nunca escribo o reescribo sobre el bootloader, ni utilizo una página o sector ocupada por el Bootloader, porque si se está ejecutando en ese momento, se quedará bloqueado. Cuando el bootloader graba el firmware, lo hace a partir de la siguiente página o sector libre, y el borrado de la flash también lo hace a partir de la página que ocupa el firmware, el bootloader siempre queda intacto.
(http://www.programering.com/images/remote/ZnJvbT1jaGluYXVuaXgmdXJsPW41R2N1WVRPMEF6TTBFVE9rRlROekVXWjFFV04xTUROelFHTTFNR000QVRZNEVqWnRNRE40SVRNeWtETXZFVE16RURNeThpTjFZVE8zOHladnhtWXYwMmJqNXladnhtWTBsbWJqNXljbGRXWXRsMkx2b0RjMFJIYQ.jpg)
Y por ultimo en tu definicion de memoria lo dividis en bootloader y programa a toda la flash o le das una direccion especifica ? por ejemplo definis una seccion llamada bootloader. me explico con el codigo que poseo:
Aunque eso signifique poner algo en ASM :/, o como indicas que se almacene en cierto lugar.. me quede con los ORG 0x00 de los pics :/
El programa o firmware, como he indicado arriba, va en la primera página libre de la flash una vez cargado el bootloader, y eso se indica en el linker script, cuando compilas, para que el enlazador lo ubique en esa dirección, sino machacaría al propio booloader. No hay que escribir nada en ensamblador.
-
Ahora entiendo.. nunca tuviste que actualizar tu bootloader por alguna razon ?.
Y desde ya gracias planeta...
-
el CD que supongo que no esta disponible para descargar por internet verdad?, por cierto, no te vendrá un esquematico con la referencia del joystick que te trae la placa whaveshare? estoy buscando uno para mi proyecto pero todos los que encuentro están obsoletos.
El CD, es realmente un DVD con casi 4Gb de información, tutoriales, esquemas, datasheet, y ejemplos.
He sacado los programas ejemplo para todos los F407, y los he colgado en Mega, en un RAR que ocupa 180 megas. Hay más ejemplos para otros STM32 F1, F2, F3.
El esquema está, pero no pone la referencia del joystick.
Ahí van los enlaces, para las descargas de Mega:
Esquema Waveshare Open407V-D (https://mega.co.nz/#!0clC1CBJ!Lb6nz_ngDmlyNtNd8pbhc7nNFQtyqMxJZE8V2PpjY4E)
Proyectos Ejemplo para STM32F407 (https://mega.co.nz/#!kYshGaya!Y8Ga1dVBar0Vlh6Tc4gO11Zim-MlldJYFT6XezHcX68)
-
Ahora entiendo.. nunca tuviste que actualizar tu bootloader por alguna razon ?.
No, ya me he cuidado que de funcione bien haciendo muchas pruebas antes de darle el visto bueno, aunque en caso de emergencia, con el producto en la calle, si detectara un bug en el bootloader, siempre podría hacer la operación contraria, osea crear un firmware que regrabe el bootloader.
El caso es que cuando el bootloader pasa el control al firmware, las páginas que ocupa se podrían borrar y regrabar si fuera necesario, pero si esa tarea sale mal, la placa se quedará bloqueada irreversiblemente, también si durante ese proceso se cortara la corriente eléctrica, no habría manera de volver a cargar el bootloader y el cliente tendría que envíar la placa para reprogramarla.
Solo contemplo un caso en el que podría borrar el bootloader, es si detecto una placa pirateada, en ese caso desde el firmware podría destruir el bootloader para dejar la placa inservible. :D :D
-
El CD, es realmente un DVD con casi 4Gb de información, tutoriales, esquemas, datasheet, y ejemplos.
He sacado los programas ejemplo para todos los F407, y los he colgado en Mega, en un RAR que ocupa 180 megas. Hay más ejemplos para otros STM32 F1, F2, F3.
El esquema está, pero no pone la referencia del joystick.
En un rato pongo los enlaces para la descarga de los ejemplos y el esquema.
Muchas gracias amigo estoy deseando tener mi hardware en las manos para probar todo lo que me estas enseñando jeje,
por cierto estas son algunas de las características que de momento tiene:
STM32f439
128 Mbits de memoria SDRAM externa
32 Mbits de nor Flash externa
ethernet 10/100 con PHY
x2 USB FS 2.0 OTG
x1 USB HS 2.0 OTH (480Mb/s) con PHY
x1 Bus can
pantalla 5,7" RGB interface 24Bits y panel tactil capacitivo
lector de tarjetas microSD (Esto lo puse porque me convenciste del bootloader por tarjeta)
y algunas cositas mas que todavia estoy diseñando un saludo
-
¿ Para que usas la flash externa ?.
Podrías usar la tarjeta SD como si fuera un disco FAT32, con una capacidad de almacenamiento muy superior.
-
la he puesto para probar el boot alternativo, simplemente por eso pero no por que me haga falta, de todas formas quizá la elimine del diseño final, pero me parecia interesante tenerla para probar el boot este que nunca he utilizado.
-
Otras rutinas que necesitaré, son las que comprueban si hay o no cargada una aplicación de usuario (firmware) para saltar a ella o no. Si no hay firmware cargado y no hemos puesto una tarjeta SD con el firmware, el bootloader se debe de quedar a la espera de la tarjeta SD o entrar en un bucle infinito while (1).
Definición de dirección inicial del firmware, en este caso la primera dirección del Sector 4 del STM32F407. Se reservarían los primeros 64K para el Bootloader (Sectores 0 a 3, de 16K cada uno).
#define USER_CODE_FLASH ((u32)0x08010000)
Rutina que comprueba si hay firmware cargado. No entiendo todavia que está haciendo ese if ((sp & 0xFFFE7FFF) == 0x20000000). Entiendo que si no hay firmware, la dirección 0x08010000 estará a 0xFFFFFFFF.
bool checkUserCode (u32 usrAddr) {
u32 sp = *(vu32*) usrAddr;
if ((sp & 0xFFFE7FFF) == 0x20000000) {
return (TRUE);
} else {
return (FALSE);
}
}
Si hay firmware cargado, salta a aplicación de usuario.
if (checkUserCode(USER_CODE_FLASH)) {
jumpToUser(USER_CODE_FLASH);
Rutina para saltar a aplicación de usuario (firmware). De ahí sobran algunas cosas, porque está sacada de un bootloader USB. No entiendo porque le suma 0x04 a la dirección a la que ha de saltar, tendré que hacer pruebas y leer más documentación, por lo que he visto tiene algo que ver con lo que llaman "Vector table", Reset Vector y las interrupciones.
void jumpToUser (u32 usrAddr) {
typedef void (*funcPtr)(void);
u32 jumpAddr = *(vu32*) (usrAddr + 0x04); /* reset ptr in vector table */
funcPtr usrMain = (funcPtr) jumpAddr;
/* tear down all the dfu related setup */
// disable usb interrupts, clear them, turn off usb, set the disc pin
// todo pick exactly what we want to do here, now its just a conservative
#ifdef STM32F2
nvicDisableInterrupts();
#else
flashLock();
usbDsbISR();
nvicDisableInterrupts();
usbDsbBus();
#endif
systemReset(); // resets clocks and periphs, not core regs
__MSR_MSP(*(vu32*) usrAddr); /* set the users stack ptr */
setPin(LED_BANK,LED);
usrMain(); /* go! */
}
-
Gracias a la información de los foros de ST, voy entendiendo algunas cosas, y considerando otras que desconocía.
Resumiento, sobre mis últimas dudas:
La dirección de salto a la aplicación de usuario, debe de ser la Primera dirección de la aplicación + 4, ya que en la dirección inicial está la Tabla de Vectores, no el código ejecutable. Así que la llamada a la aplicación de usario podría quedar así, donde ApplicationAdress en mi caso estaría en 0x08010000:
pFunction Start = *(__IO uint32_t*) (ApplicationAddress + 4);
__set_MSP(*(__IO uint32_t*)ApplicationAddress);
Start();
En la aplicación de usuario (firmware), además de modificar el Linker Script para que la ROM ORIGIN apunte a la dirección 0x08010000, también hay que añadir esto dentro del main(), para reubicar la Tabla de Vectores (desconozco el porqué, pero hay que hacerlo).
NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x10000);
Y cuando uno está de suerte, está de suerte, en los foros de ST, alguien publicó hace 3 años un bootloader para tarjetas SD con un STM32F103VC, no incluye encriptación, y requiere cambiar unas cuantas cosillas para adaptarlo a los STM32F4xx, pero el 80% del trabajo ya está hecho. El enlace de la descarga es este: http://www.mediafire.com/?2748w3w5kraifsv . Gracias Benjamin ;-) ;-). Y si alguien lo quiere para los pequeñitos SMT32F1xx, pues ya lo tiene al 100%, solo falta añadirle las rutinas de desencriptación y arreando (XTEA, DES, AES...).
Y aquí algunos post interesantes de los foros de ST, sobre estas cuestiones:
Post 1 (https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fSTM32F2xx%20IAP%20question&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=371)
Post 2 (https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fSelf%20made%20bootloader&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=2925)
Post 3 (https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fCustom%20Bootloader&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=4174)
-
La dirección de salto a la aplicación de usuario, debe de ser la Primera dirección de la aplicación + 4, ya que en la dirección inicial está la Tabla de Vectores, no el código ejecutable. Así que la llamada a la aplicación de usario podría quedar así, donde ApplicationAdress en mi caso estaría en 0x08010000:
En mi caso con el de TI el vector de reset se encuentra en una posicion + 4 tambien. Ya que la direccion (u offset) 0x0000.0000 se encuentra definido el top del stack, esto es lo que dice:
"Stack top is loaded from the first entry of the vector table on reset."
Luego como dije esta el vector de reset.
Y el tema del NVIC tmb.. para reubicar la tabla de vectores de excepciones e interrupciones.
Nuevamente gracias a vos cuando lei eso fui corriendo al datasheet y me ponia a pensar por que se ejecutaba el bootloader que posee la ROM cuando la direccion 0x0000.0004 estaba borrada 0xFF, por que no directamente lo hacia de la direccion 0x0000.0000 y ahora lo descubri
-
Hola un saludo, hace tiempo que conocía el foro como visitante, pero hoy he decidido registrarme, para ver si aprendo algo de ARM y puedo colaborar en algún tema.
“Mis conocimientos son sobre todo de los PIC de 8 bit, en ASM.”
Me parece interesante este tema de bootloader por tarjeta SD, a ver si me puedo píllame alguna placa de desarrollo y realizo mis pruebas.
Veo que tiene cosas interesantes cono ID serie del dispositivo, por cierto como sea comentado puede ser muy útil.
Pero tengo algunas dudas:
Si protegido el bootloader, se puede hacer alguna lectura de su código (cargando alguna rutina que pueda leer esos datos y sacarlos hacia fuera)??
En esto micro STM32F4xxxx, puede ejecutar código desde la RAM ¿?
Donde indicáis:
ROM (rx) : ORIGIN = 0x08000000, LENGTH = 1024K
La longitud 1024K hay que quitarle lo que ocupa el booloader (1024k – bootloader)
Perdon no lei lo que pulso el compañero, "Bueno, el tamaño de la flash disponible ya no serían 1024K, sino 1024K menos el tamaño del bootloader."
-
Si protegido el bootloader, se puede hacer alguna lectura de su código (cargando alguna rutina que pueda leer esos datos y sacarlos hacia fuera)??
No, por software no se puede extraer nada, todos aquellos inventos con programas "gusano" que permitían antaño volcar cosas en micros PIC, allá por el año 2000, no sirve con estos micros. Además como el firmware está encriptado, nadie puede cargar nada, a menos que conozca la clave de encriptación.
En esto micro STM32F4xxxx, puede ejecutar código desde la RAM ¿?
Lo desconozco, algo he oido, pero no lo he probado. De todas formas con 1 y 2 Megas de flash, no creo que necesites hacer uso de la RAM para cargar un programa.
Donde indicáis:
ROM (rx) : ORIGIN = 0x08000000, LENGTH = 1024K
La longitud 1024K hay que quitarle lo que ocupa el booloader (1024k – bootloader)
Perdon no lei lo que pulso el compañero, "Bueno, el tamaño de la flash disponible ya no serían 1024K, sino 1024K menos el tamaño del bootloader."
Si, eso le indica al enlazador cuanta RAM y Flash tiene para ubicar variables y programa, y en que direccion empieza cada memoria. Si le pones datos incorrectos, aunque compile, cuando lo cargues al micro no funcionará.
-
"Además como el firmware está encriptado, nadie puede cargar nada, a menos que conozca la clave de encriptación."
Tienes razón, pero mi idea es que un usuario pueda subir su aplicación al micro, entonces si en su aplicación indica que lea direcciones de memoria y que las saque hacia fuera. Se jode el invento.
Lo ideal es tener una zona de memoria que este protegida sobre lectura, no tengo ni idea si se puede hacer alguien se le ocurre algo ¿??
Mi otra idea es que se pueda ejecutar código desde la tarjeta sd, posiblemente el código hay que pasarlo a la ram, Pero esta la duda si puede ejecutar código desde la ram.
-
"Además como el firmware está encriptado, nadie puede cargar nada, a menos que conozca la clave de encriptación."
Tienes razón, pero mi idea es que un usuario pueda subir su aplicación al micro, entonces si en su aplicación indica que lea direcciones de memoria y que las saque hacia fuera. Se jode el invento.
Es que la utilidad de un bootloader encriptado no es esa. El firmware está encriptado precisamente para que NADIE pueda subir lo que quiera, solo la empresa que fabrica el producto es la que facilita el firmware ya encriptado al cliente.
Lo ideal es tener una zona de memoria que este protegida sobre lectura, no tengo ni idea si se puede hacer alguien se le ocurre algo ¿??
¿ pero que quieres proteger ?, si es al propio bootloader no tiene sentido, son programas sencillos al alcance de cualquiera. Nadie hackea un microcontrolador para sacar su bootloader, por la red tienes montones de código fuente para hacer tu propio booloader, sin coste alguno.
Mi otra idea es que se pueda ejecutar código desde la tarjeta sd, posiblemente el código hay que pasarlo a la ram, Pero esta la duda si puede
ejecutar código desde la ram.
¿ Código desde una tarjeta SD ?, ahí si que lo puede ver y copiar cualquiera, e igualmente pueden hacer lo que dices al principio.
No entiendo lo que quieres hacer.
-
Por cierto para manejar ehrtenet tengo que añadir algun circuito mas, algo he leido por algun sitio pero no lo tengo claro.
-
Para Ethernet necesitarás el transceptor para la capa física o un controlador Ethernet por SPI si el micro no tiene Ethernet integrado. Para el primero puedes usar el DP83848, y para el segundo el ENC28J60.
-
Podeis echar un vistazo aki, http://openservodrive.com/resetting-stm32-option-bytes/ dice algo de desblokear la escritura.
-
Muy interesante!, voy a leer el hilo y descargar los ejemplos, yo hace rato quiero implementar un programa con stm32f4 para el uso de tarjetas sd de más de 2gb FAT32
Con freescale implementé FAT16 con las notas de aplicación que ellos tienen en la pagina y anda muy bien.
-
Muy interesante!, voy a leer el hilo y descargar los ejemplos, yo hace rato quiero implementar un programa con stm32f4 para el uso de tarjetas sd de más de 2gb FAT32
Con freescale implementé FAT16 con las notas de aplicación que ellos tienen en la pagina y anda muy bien.
Yo ahora estoy creando un bootloader encriptado para Kinetis, uso las mismas rutinas de desencriptación XTEA que ya cree para los PIC32, y el programa de PC para encriptar es el mismo.
Para los STM32, tienes la librería FATFS, recomendable conectar el tarjetero por SDIO, no por SPI o la cosa se complica mucho. Si lo implementas con Cubemx, prácticamente se generan todas las funciones automáticamente, apenas tienes que escribir código.
Precisamente hoy he recibido un email de novedades de ST, y me ha llamado la atención unas librerías de encriptación que han liberado para los STM32 con Cubemx. Las tengo que probar porque trabajar con Cubemx es una gozada.
http://www.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-expansion-software/x-cube-cryptolib.html?ecmp=tt4639_gl_enews_jan2017
-
Hola planeta y gente del foro. Estoy un poco complicado con un proyecto al cual le falta la posibilidad de actualizar el firmware del stm32f407vgt6 (el de la discovery). Yo nunca implemente un bootloader, estuve leyendo pero me cuesta entender sin un ejemplo concreto. Planeta, tienes un ejemplo para poder comenzar y cargar mi primer bootloader al micro? podrías subirlo para poder hacer pruebas?, no se si lo puedes subir como proyecto para ir viendo la estructura y entenderlo de una vez.
de lo que estuve leyendo entiendo:
en la dirección ORIGIN = 0x08000000 va el bootloader y desde la siguiente página libre después de bootloader va la aplicación del usuario. También vi en el tema las distintas funciones del bootloader pero necesitaría saber también si el bootleader puede recibir el firmware del usuario por un uart de un gprs por ejemplo que es lo que estoy necesitando hacer y por eso necesito la ayuda de uds. (después veré como envío el archivo del firmware por gprs al módulo y éste ue lo envíe por uart al bootloader del micro...)
Muchas gracias!
-
Visita el sitio web de uTasker, ahí lo tienes todo documentado, incluso con videos de instalación y configuración.
Yo lo tengo aplicado a los Kinetis, no lo probé con STM32 porque dejé de usarlos, y ahora estoy migrando todo a NXP RT1020.
Solo uso bootloader con tarjetas SD, supongo que podrá funcionar con otros periféricos, pero nunca lo he probado.
En cuanto a la dirección del firmware de usuario, por una parte se configura en el linker script, y por otra parte está en alguno de los fuentes del bootloader, pero yo eso no lo cambiaría porque el tamaño asignado al bootloader es el adecuado, y la primera página libre para el firmware de usuario es la que sigue al bootloader.
-
cual fue el desenlace del tema? se logro el objetivo? sigo sus paso me gustaria compartieran informacion
-
cual fue el desenlace del tema? se logro el objetivo? sigo sus paso me gustaria compartieran informacion
No hace falta inventar lo que ya existe. Puedes usar uTasker, yo lo tengo implementado para los Kinetis y va muy bien. Con los STM32 ya no trabajo desde hace tiempo, prefiero seguir con los RT1020 de NXP.
Aquí tienes el hilo que abrí hace tiempo sobre el uTasker para los STM32.
http://www.todopic.com.ar/foros/index.php?topic=48161.0