I want to jump from my application to the bootloader ( I load via bluetooth and have an application command to jump to the boot loader).
the following work :
void* bl = (void *) 0x3c00;
goto *bl;
or
asm volatile { jmp BOOTL ::}
asm volatile { .org 0x3c00
BOOTL: }
(but code size grows to 0x3c00)
BUT, the most obvious option
asm volatile { jmp 0x3c00 ::}
does not (seems it does not even produce code }
Any idea why ?
The question as stated is not clear, as to what is working and what is failing. And about your environment, which is important. That said I guess your stating the void and/or "jmp BOOTL" work as desired, but makes the code appear to be huge.
I tried it on Arduino IDE 1.0.5 and only saw less than a 1/2K of code. Note 16K or Huge.
void* bl = (void *) 0x3c00;
void setup()
{
// put your setup code here, to run once:
}
void loop()
{
goto *bl;
// put your main code here, to run repeatedly:
}
with a compile output of...
Binary sketch size: 474 bytes (of a 32,256 byte maximum)
Estimated used SRAM memory: 11 bytes (of a 2048 byte maximum)
I suspect your observation is that the linker is seeing the pointer out at 0x3C00 the location of the BOOTSECTOR (noting it is at end of code) So it only looks like it is huge. I suspect there is a lot of white space between you may want to use the "avr-objdump.exe -d output.elf" to see what it is actually doing, versus what you expect.
0x3C00 is a 16-bit word address.
Use 0x7800 in GCC if you are using goto. GCC uses byte address (0x3C00 * 2 = 0x7800).
Example:
void *bl = (void *) 0x7800;
goto *bl;
will create the following assembly language (see *.lss output file):
c4: 0c 94 00 3c jmp 0x7800 ; 0x7800 <__stack+0x6d01>
#define GO_TO_ADRR_FLASH_MEMORY_BOOT_LOADER asm volatile ("JMP 0x7800")
GO_TO_ADRR_FLASH_MEMORY_BOOT_LOADER;
Related
I have some (mostly CubeMX-generated) code:
volatile uint8_t buf[4];
int main(void)
{
...
HAL_UART_Receive_IT(&huart3, buf, sizeof(buf));
while (1)
{
/* USER CODE END WHILE */
/* USER CODE BEGIN 3 */
}
/* USER CODE END 3 */
}
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) {
if (huart->Instance == USART3) {
HAL_UART_Transmit(&huart3, buf, sizeof(buf), 0xFFFF);
HAL_UART_Receive_IT(&huart3, buf, sizeof(buf));
}
}
This successfully echos everything which is received on USART3. (This code is just a throw-away example to learn about the serial port.)
I am concerned about the time between HAL_UART_RxCpltCallback() being called and HAL_UART_Receive_IT() setting up the next receive.
Is there any feature of the STM32F103 which guarantees that data won't be lost in this interval? I haven't found any evidence of more than a two byte receive buffer on the USART.
I am particularly concerned that some higher-priority USB-device activity might delay the calling of HAL_UART_RxCpltCallback(), and so one or more characters might be lost.
Quick answer:
HAL_UART_Transmit is a blocking function, so, until it completes HAL_UART_Receive_IT is not called and the uart will surely go overflow. If you are worried of any other interrupt can preemt your execution, use dma or disable the troublesome interrupts while you issue the command. You could also rise UART interrupt priority but....
Hints:
....you should not call HAL_UART_Transmit and HAL_UART_Receive_IT within HAL_UART_RxCpltCallback as here you are in ISR mode. This cause some side issues on certain versions of the HAL framework. Better to set a flag and check for it from the main code.
Also you should really avoid the use of volatile, better if you use a compiler barrier like gcc __asm volatile("" ::: "memory")
Conventional wisdom has it that global and static data is stored in the bottom of RAM along with other stuff. Somewhere above that is the heap, then free memory and at the top of RAM, is the stack. See the code below before reading on.
When I compile this with the Arduino IDE (1.8.10) on a MEGA2560 I get the following statistics:
Sketch uses 2750 bytes (1%) of program storage space. Maximum is 253952 bytes.
Global variables use 198 bytes (2%) of dynamic memory, leaving 7994 bytes for local variables. Maximum is 8192 bytes.
If I change ARRAY_SIZE from 1 to 7001, I get exactly the same numbers. I expected that dynamic memory should increase by 7000. When I do the same comparison with AtmelStudio V7, dynamic memory does indeed increase by 7000.
One more piece of information along these lines. If I do a malloc of 7000 which is pretty close to free memory, one would expect that the malloc should be successful when ARRAY_SIZE equals one and would fail when the ARRAY_SIZE equals 7001. I was dismayed to find that the malloc was successful with both the small and the large array sizes. With AtmelStudio this does not happen.
I suspect respective compiler/linker options somewhere could explain the difference (AtmelStudio - project properties and Arduino IDE - platform.txt perhaps?).
I also suspect that the Arduino IDE dynamically allocates global variables in FlashMemory.
I am not a newbie, but I am not a guru - comments anyone?
Thanks
Michèle
#define ARRAY_SIZE 7001
uint8_t globalArray[ARRAY_SIZE]{1};
void setup() {
Serial.begin(115200);
for (int i = 0; i < ARRAY_SIZE; i++) globalArray[i] = 1;
Serial.print(F("Just initialized globalArray, size = "));Serial.println(ARRAY_SIZE);
uint8_t* testPointer = (uint8_t*) malloc(7000);
Serial.print(F("Allocation of 7000 bytes "));
if ( testPointer != (uint8_t*) 0) {
Serial.print(F("SUCCESSFUL"));
} else {
Serial.print(F("NOT SUCCESSFUL"));
}
} // setup
void loop() {} // loop
I ran some more tests to figure out why AtmelStudio and the Arduino IDE are supplying vastly different RAM usage values after declaring an array. The response from juraj (thank you) was that the compiler optimized unused code away. This answer was true however I had included an array initialization loop to make sure that the compiler would include the array in the code.
It turns out that AtmelStudio and the Arduino IDE have different criteria as to code what it means "code being used". The outcome is that globalArray, in the initialization line,
for (int i = 0; i < ARRAY_SIZE; i++) globalArray[i] = 1;
is considered by AtmelStudio as being used and by the Arduino IDE as not being used.
The Arduino IDE requires that globalArray appear on the left of an assignment statement to consider it as being used thus the need for the "a+=globalArray[i];" line. The exact same code below reports:
a+=globalArray[i]; not used
Atmel Studio: Data Memory Usage as being 7211 bytes
Arduino IDE: Global variables use 198 bytes
a+=globalArray[i]; used
Atmel Studio: Data Memory Usage as being 7211 bytes
Arduino IDE: Global variables use 7199 bytes
Q.E.D. Interesting how the two IDEs do not quite mean the same thing with "being used".
Thanks - My first time on this forum got my question answered rather quickly.
Michèle
#define ARRAY_SIZE 7001
uint8_t globalArray[ARRAY_SIZE];
void setup() {
Serial.begin(115200);
for (int i = 0; i < ARRAY_SIZE; i++) globalArray[i] = 1;
Serial.print(F("Just initialized globalArray, size = "));
Serial.println(ARRAY_SIZE);
// uint16_t a {0};
// for (int i = 0; i < ARRAY_SIZE; i++) a+=globalArray[i];
// Serial.print(F("Value of a = ")); Serial.println(a);
uint8_t* testPointer = (uint8_t*) malloc(7000);
Serial.print(F("Allocation of 7000 bytes "));
if ( testPointer != (uint8_t*) 0) Serial.print(F("SUCCESSFUL"));
else Serial.print(F("NOT SUCCESSFUL"));
} // setup
I'm experiencing unexpected results using wiringPi's wiringPiI2CWriteReg16() function, and I'm not sure if it's due to incorrect usage, or something else. This is the declaration for the function:
extern int wiringPiI2CWriteReg16 (int fd, int reg, int data);
There are notes within the wiringPiI2C.c file that state it resembles Linux's SMBus code, if that helps.
On my Arduino (both an Uno R3 and a Trinket Pro), I am running this pared-down sketch:
#include <Wire.h>
#define SLAVE_ADDR 0x04
void receive_data (int num_bytes){
Serial.print("bytes in: ");
Serial.println(num_bytes);
while(Wire.available()){
int data = Wire.read(); // tried char, uint8_t etc
Serial.println(data);
}
Serial.print("\n");
}
void setup() {
Serial.begin(9600);
Wire.begin(SLAVE_ADDR);
Wire.onReceive(receive_data);
}
void loop() {
delay(500);
}
I would think that Wire.read() would break things apart at the byte boundary, but that's not occurring in my case. Perhaps this is my issue... a misunderstanding.
Nonetheless, I have this C code (requires wiringPi v2.36+ to be installed):
// word.c
#include <wiringPiI2C.h>
void main (){
int fd = wiringPiI2CSetup(0x04);
wiringPiI2CWriteReg16(fd, 0x00, 255);
wiringPiI2CWriteReg16(fd, 0x01, 256);
}
Compiled like this:
gcc -o word word.c -lwiringPi
When run, ./word, I receive the following on my Arduino's serial output:
bytes in: 3
0
255
0
bytes in: 3
1
0
1
In the first call to wiringPiI2CWriteReg16(), I expect the first byte in the output to be zero (0x00) as that's the register address I'm requesting. The second byte (255) is also correct. The third byte (0) is meaningless from what I can tell (as I'm only sending in one byte as data).
However, in the second call to that function, I do get the correct output for the register (first byte as 0x01 == 1), but the second byte is zero, and the third byte has what appears to be the correct remainder (255 == one byte, + 1). The problem is, is that the second byte is 0.
The exact same effect happens if I pass in 511 or for that matter, any number as the data in the call.
My question is whether I'm missing something glaringly obvious (I'm relatively new to C and Arduino), and/or if I can get some pointers on how to troubleshoot this more thoroughly.
I found that the problem was in my Arduino code. In the official Raspi forums, Gordon tipped me off that the bytes are read in separately, LSB first. Throughout all of my searching, I hadn't come across that, and really didn't quite understand what was happening. After changing my I2C read loop code in my Arduino sketch to this:
while(Wire.available()){
Wire.read(); // throw away register byte
int16_t data = Wire.read(); // LSB
data += Wire.read() << 8; // MSB
Serial.print("data: ");
Serial.println(data);
}
...everything works. In effect, that's at least one way to read two-byte values over I2C on the Arduino and put the bytes back together.
I am trying using the arduino IDE to write a sketch. I have data in progmem and want to move the data with a function to a memory address allocated using malloc. My code is below:
const uint8_t Data_6 [256] PROGMEM = { 0x11, 0x39......};
void setup() {
Serial.begin(57600);
oddBallData (Data_6, 0x00, 256);
}
void main() {
}
void oddBallData(const uint8_t *data, uint8_t mem, uint16_t bytes) {
uint8_t *buff1 = (uint8_t*)malloc(sizeof(bytes));
if (buff1 = 0) {
Serial.println(F("FATAL ERROR - NO MEMORY"));
}
else {
for (uint16_t x = 0; x < 6; x++ ) {
buff1[x] = data[x]; //edited from data[0] to [x] made a mistake in post
Serial.println(buff1[x],HEX);
}
}
buff1[0] = data[0];
Serial.println(buff1[0],HEX);
free(buff1);
}
I have some data saved in progmem and want to write that data to a second device using i2c protocol. I have multiple constant arrays of data saved to my progmem, with different sizes. So I have used malloc to reserve some memory from the heap, inside of the function.
I have not been able to write the data from the progmem so I have stripped things back to so that I am just trying to point to the progmem data using malloc and then print it.
This is where I found a the problem. If I print a single array entry from the data constant. It prints the correct value. If I use a loop I get mixed results, the loop works as long as the condition check value is below 3 or sometimes below 6!!!...?
If above this value the entire print is just garbage. Can anyone explain what I am seeing?
The culprit is probably
uint8_t *buff1 = (uint8_t*)malloc(sizeof(bytes));
sizeof(bytes) returns the size of the variable (which is probably 2 bytes) so you are just allocating 2 bytes of memory. You should use the value directly, eg:
uint8_t* buff1 = malloc(bytes);
Mind that the cast is not required in C since a void* is convertible to any other pointer type directly.
Again - AVR PROGMEM is not directly accessible from memory space, it needs different instruction than access into the RAM. If you are using it like this, you'll get RAM content on passed address, not the FLASH one. You have to use special functions for this. For example memcpy_P(ram_buff,flash_ptr); makes a copy from flash into the ram. Or you can read one byte by pgm_read_byte(flash_ptr + offset)
BTW: If you are using Data_6[0] and it's working, it's just because compiler sees it as a constant and constant can be replaced by its value compile time.
I Guess you just forgot to flush()
try to do Serial.flushI() after Serial.println(buff1[x],HEX);
you can also check flush documentation
have C sources that must compile in 32bit and 64bit for multiple platforms.
structure that takes the address of a buffer - need to fit address in a 32bit value.
obviously where possible these structures will use natural sized void * or char * pointers.
however for some parts an api specifies the size of these pointers as 32bit.
on x86_64 linux with -m64 -mcmodel=small tboth static data and malloc()'d data fit within the 2Gb range. data on the stack, however, still starts in high memory.
so given a small utility _to_32() such as:
int _to_32( long l ) {
int i = l & 0xffffffff;
assert( i == l );
return i;
}
then:
char *cp = malloc( 100 );
int a = _to_32( cp );
will work reliably, as would:
static char buff[ 100 ];
int a = _to_32( buff );
but:
char buff[ 100 ];
int a = _to_32( buff );
will fail the assert().
anyone have a solution for this without writing custom linker scripts?
or any ideas how to arrange the linker section for stack data, would appear it is being put in this section in the linker script:
.lbss :
{
*(.dynlbss)
*(.lbss .lbss.* .gnu.linkonce.lb.*)
*(LARGE_COMMON)
}
thanks!
The stack location is most likely specified by the operating system and has nothing to do with the linker.
I can't imagine why you are trying to force a pointer on a 64 bit machine into 32 bits. The memory layout of structures is mainly important when you are sharing the data with something which may run on another architecture and saving to a file or sending across a network, but there are almost no valid reasons that you would send a pointer from one computer to another. Debugging is the only valid reason that comes to mind.
Even storing a pointer to be used later by another run of your program on the same machine would almost certainly be wrong since where your program is loaded can differ. Making any use of such a pointer would be undefined abd unpredictable.
the short answer appears to be there is no easy answer. at least no easy way to reassign range/location of the stack pointer.
the loader 'ld-linux.so' at a very early stage in process activation gets the address in the hurd loader - in the glibc sources, elf/ and sysdeps/x86_64/ search out elf_machine_load_address() and elf_machine_runtime_setup().
this happens in the preamble of calling your _start() entry and related setup to call your main(), is not for the faint hearted, even i couldn't convince myself this was a safe route.
as it happens - the resolution presents itself in some other old school tricks... pointer deflations/inflation...
with -mcmodel=small then automatic variables, alloca() addresses, and things like argv[], and envp are assigned from high memory from where the stack will grow down. those addresses are verified in this example code:
#include <stdlib.h>
#include <stdio.h>
#include <alloca.h>
extern char etext, edata, end;
char global_buffer[128];
int main( int argc, const char *argv[], const char *envp )
{
char stack_buffer[128];
static char static_buffer[128];
char *cp = malloc( 128 );
char *ap = alloca( 128 );
char *xp = "STRING CONSTANT";
printf("argv[0] %p\n",argv[0]);
printf("envp %p\n",envp);
printf("stack %p\n",stack_buffer);
printf("global %p\n",global_buffer);
printf("static %p\n",static_buffer);
printf("malloc %p\n",cp);
printf("alloca %p\n",ap);
printf("const %p\n",xp);
printf("printf %p\n",printf);
printf("First address past:\n");
printf(" program text (etext) %p\n", &etext);
printf(" initialized data (edata) %p\n", &edata);
printf(" uninitialized data (end) %p\n", &end);
}
produces this output:
argv[0] 0x7fff1e5e7d99
envp 0x7fff1e5e6c18
stack 0x7fff1e5e6a80
global 0x6010e0
static 0x601060
malloc 0x602010
alloca 0x7fff1e5e69d0
const 0x400850
printf 0x4004b0
First address past:
program text (etext) 0x400846
initialized data (edata) 0x601030
uninitialized data (end) 0x601160
all access to/from the 32bit parts of structures must be wrapped with inflate() and deflate() routines, e.g.:
void *inflate( unsigned long );
unsigned int deflate( void *);
deflate() tests for bits set in the range 0x7fff00000000 and marks the pointer so that inflate() will recognize how to reconstitute the actual pointer.
hope that helps if anyone similarly must support structures with 32bit storage for 64bit pointers.