STM32 HAL_FLASH_Program not working as expected - stm32

I'm trying to program FLASH using HAL_FLASH_Program() function. Precisely speaking, I've written a function which is expected to write two measurements
to flash at a set time interval (e.g. 3 seconds). However, when called, the function manages to write only the first one while ignoring the second one. Can't HAL_FLASH_Program be used twice? What am I doing wrong? I just want to mention that I'm utterly new to STM32 programming, so any helpful suggestions would be much appreciated. Here is the code:
void writeFlash(void){
mem = returnPointerToFirstEmptyAddressInSector();
Address = (uint32_t)mem;
var1.f = Temperature;
var2.f = SD;
HAL_FLASH_Unlock();
__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_EOP | FLASH_FLAG_OPERR | FLASH_FLAG_WRPERR | FLASH_FLAG_PGAERR | FLASH_FLAG_PGSERR | FLASH_FLAG_PGPERR);
HAL_FLASH_Program(TYPEPROGRAM_WORD, Address, var1.i );
Address++;
HAL_FLASH_Program(TYPEPROGRAM_WORD, Address, var2.i);
HAL_FLASH_Lock();
}

The address is not properly aligned
The declaration of Address is not shown, but from the line
Address = (uint32_t)mem;
I'd guess it's an unsigned long. Later, you are incrementing Address after the first write with
Address++;
and use this value to program the second value. But since Address is presumably an integer, not a pointer type, it would be incremented by one instead of the word size (4), and pointing to an address that is partially overlapping the previously written value, and not aligned for word-sized writes. The second write operation would inevitably fail. As #JMA suggests in the comments, check the return value of HAL_FLASH_Program(), and the error code
uint32_t ret = HAL_FLASH_Program(TYPEPROGRAM_WORD, Address, var2.i);
switch(ret) {
case HAL_OK:
break;
case HAL_TIMEOUT:
printf("HAL_FLASH_Program() timeout!\n");
break;
case HAL_ERROR:
printf("HAL_FLASH_Program() error 0x%08x, see *hal_flash.h for bit definitions\n", HAL_FLASH_GetError());
break;
default:
printf("HAL_FLASH_Program() returned unknown status %lu\n", ret);
}
Write a double word at once
The HAL library supports writing 64 bit values at once, so you can write two 32 bit integers in one operation.
HAL_FLASH_Program(TYPEPROGRAM_DOUBLEWORD, Address, ((uint64_t)var2.i << 32) | var1.i);
Just ensure that Address is aligned to a doubleword boundary, i.e. divisible by 8.

Related

XDP program ipheader, data, nh_off confusion

I'm studying XDP codes right now and I'm having some confusion as regards to how programs approach certain parts of a packet header.
So! When I look at the code that gets the IP address of a packet, it goes like:
static inline int parse_ipv4(void *data, u64 nh_off, void *data_end) {
struct iphdr *iph = data + nh_off;
if ((void*)&iph[1] > data_end)
return 0;
return iph->protocol;
}
Now here are some things that confuse me :
struct iphdr *iph = data + nh_off;
I thought nh_off is the offset value to the next header, so if you add data + nh_off, shouldn't that take you to the next packet?
Because to my understanding, if you add next header offset to the data, there should be a next packet waiting to be processed!
What does
(void*)&iph[1]
do exactly? I tried to guess what this line of code does for a few days but I still have no clue at all.
I am so sorry if my questions are too absorb or vague.. This things have been bothering me for a while and I would greatly appreciate it if someone could share their knowledge with me. Thank you so much in advance.
It all depends on your code, since I don't see how nh_off is defined in your case. But most of the time, it does point to the next header, so we would have:
nh_off being the offset of the next header after Ethernet header has been parsed, i.e. nh_off is the offset of the IP header in the packet (typically, it's set to 14 at this stage, the number of bytes in the Ethernet header if no VLAN/encap is used).
Setting struct iphdr *iph = data + nh_off; declares and initialises iph as a struct iphdr pointer, so we can reuse it afterwards to easily reach each field from the IPv4 header. It points to data + nh_off, i.e. the beginning of the packet plus the offset at which the IPv4 header begins in the packet.
Next packet to be processed is not accessible from within your eBPF program; you would get a new ctx with a data pointer pointing to it when that new packet is processed with a new call to the BPF program, but you only see just one packet at once.
So iph points to the beginning of your IPv4 header. We can use that pointer to easily reach the individual fields (e.g. iph->protocol to get L4 protocol). But before we do that we must ensure that the packet is long enough and actually contains those field. Otherwise we could do an out-of-bound access (therefore the verifier would reject the program in the first place). This is the check we do here: if ((void*)&iph[1] > data_end) return 0;
In that verification, (void*)&iph[1] means: i) Consider a struct iphdr * array (&iph, a pointer to a pointer to a struct iphdr). ii) Take the second cell of that array, e.g. the address of the struct pointed by the second struct iphdr *, e.g. the address of the byte that starts right after the first struct iphdr in the packet. And iii) cast it as a void * so we can compare it with data_end. In other words, this is a way to compare data_end (the address in memory right after the last byte of the packet) and the address of the byte right after IPv4 header (so possibly first byte of L4 is packet is long enough). If (void*)&iph[1] is bigger than data_end, then the IPv4 header we considered is longer than the actual packet we got, and we cannot afford to dereference iph to try to reach e.g. the protocol field.
With a diagram, maybe:
Packet data
| Ethernet | IPv4 | IPv4 data (e.g. L4, data) |
+--------------+--------------------+------ ... ----------------------+
^ ^ ^ ^
data data + nh_off | data_end
iph |
&iph[0] &iph[1]
We would have an issue to access iph->protocol if we had the following instead (this is why we return 0 if the comparison succeeds):
Packet data
| Ethernet | <something> | End of packet
+--------------+---------------- +
^ ^ ^ ^
data data + nh_off | |
iph | |
&iph[0] | &iph[1]
data_end

When can TLM peek fail?

I was working on OVM driver sequencer communication. I am using try_get_item() in ovm driver but it is still getting stuck. In my sequencer I redefined try_next_item and just printed a display statement before and after m_req_fifo.peek(t); The statement before peek got executed but not the statement after the peek. I even displayed size of the m_req_fifo using m_req_fifo.size() and it printed out 1. Why is peek not returning anything even after the size is 1? The modified try_next_item (Just addition of display) is given below.
The line After PEEK never gets executed after the line Line 398 with fifo size 1
virtual task try_next_item(output REQ t);
int selected_sequence;
time arb_time;
ovm_sequence_base seq;
if (get_next_item_called == 1) begin
ovm_report_error(get_full_name(), "get_next_item/try_next_item called twice without item_done or get in between", OVM_NONE);
return;
end
wait_for_sequences();
selected_sequence = choose_next_request();
if (selected_sequence == -1) begin
t = null;
return;
end
set_arbitration_completed(arb_sequence_q[selected_sequence].request_id);
seq = arb_sequence_q[selected_sequence].sequence_ptr;
arb_sequence_q.delete(selected_sequence);
m_update_lists();
sequence_item_requested = 1;
get_next_item_called = 1;
$display("Line 398 with fifo size %0d\n", m_req_fifo.size());
m_req_fifo.peek(t);
$display("After PEEK\n");
wait_for_sequences();
// attempt to get the item; if it fails, produce an error and return
if (!m_req_fifo.try_peek(t))
ovm_report_error("TRY_NEXT_BLOCKED", {"try_next_item: the selected sequence '",
seq.get_full_name(), "' did not produce an item during wait_for_sequences(). ",
"Sequences should not consume time between calls to start_item and finish_item. ",
"Returning null item."}, OVM_NONE);
endtask
uvm_tlm_fifo::size() doesn't return the number of elements in the FIFO, but its capacity (i.e. the maximum number of elements it can hold). The function you're looking for is uvm_tlm_fifo::used() which returns the number of stored elements.
The function names are not intuitive at all and I remember spending a couple of hourse trying to understand some similar code to the one you had until noticing in the documentation that I was using the wrong method.

Can pysnmp return octectstring values only

I am doing a small script to get SNMP traps with PySnmp.
I am able to get the oid = value pairs, but the value is too long with a small information in the end. How can I access the octectstring only which comes in the end of the value. Is there a way other than string manipulations? Please comment.
OID =_BindValue(componentType=NamedTypes(NamedType('value', ObjectSyntax------------------------------------------------(DELETED)-----------------(None, OctetString(b'New Alarm'))))
Is it possible to get the output like the following, as is available from another SNMP client:
.iso.org.dod.internet.private.enterprises.xxxx.1.1.2.2.14: CM_DAS Alarm Traps:
Edit - the codes are :
**for oid, val in varBinds:
print('%s = %s' % (oid.prettyPrint(), val.prettyPrint()))
target.write(str(val))**
On screen, it shows short, but on file, the val is so long.
Usage of target.write( str(val[0][1][2])) does not work for all (program stops with error), but the 1st oid(time tick) gets it fine.
How can I get the value from tail as the actual value is found there for all oids.
Thanks.
SNMP transfers information in form of a sequence of OID-value pairs called variable-bindings:
variable_bindings = [[oid1, value1], [oid2, value2], ...]
Once you get the variable-bindings sequence from SNMP PDU, to access value1, for example, you might do:
variable_binding1 = variable_bindings[0]
value1 = variable_binding1[1]
To access the tail part of value1 (assuming it's a string) you could simply subscribe it:
tail_of_value1 = value1[-10:]
I guess in your question you operate on a single variable_binding, not a sequence of them.
If you want pysnmp to translate oid-value pair into a human-friendly representation (of MIB object name, MIB object value), you'd have to pass original OID-value pair to the ObjectType class and run it through MIB resolver as explained in the documentation.
Thanks...
the following codes works like somwwhat I was looking for.
if str(oid)=="1.3.6.1.2.1.1.3.0":
target.write(" = str(val[0][1]['timeticks-value']) = " +str(val[0][1]['timeticks-value'])) # time ticks
else:
target.write("= val[0][0]['string-value']= " + str(val[0][0]['string-value']))

Different offset in libc's backtrace_symbols() and libunwind's unw_get_proc_name()

I make a stack trace at some point in my program. Once with libc's backtrace_symbols() function and once with unw_get_proc_name() from libunwind.
backtrace_symbols() output:
/home/jj/test/mylib.so(+0x97004)[0x7f6b47ce9004]
unw_get_proc_name() output:
ip: 0x7f6b47ce9004, offset: 0x458e4
Here you see that the instruction pointer address (0x7f6b47ce9004) is the same and correct. The function offset 0x97004 from backtrace_symbols() is also correct but not the one I get from unw_get_proc_name() (0x458e4).
Does somebody have a clue what's going on here and what might cause this difference in offsets?
Both methods use a similar code like the following examples:
backtrace():
void *array[10];
size_t size;
size = backtrace(array, 10);
backtrace_symbols_fd(array, size, STDERR_FILENO);
libunwind:
unw_cursor_t cursor;
unw_context_t context;
unw_getcontext(&context);
unw_init_local(&cursor, &context);
while (unw_step(&cursor) > 0) {
unw_word_t offset, pc;
char fname[64];
unw_get_reg(&cursor, UNW_REG_IP, &pc);
fname[0] = '\0';
(void) unw_get_proc_name(&cursor, fname, sizeof(fname), &offset);
printf ("%p : (%s+0x%x) [%p]\n", pc, fname, offset, pc);
}
I think unw_get_proc_name compute offset from an unnamed internal frame.
For example:
void f() {
int i;
while (...) {
int j;
}
}
Notice there is a variable declaration inside loop block. In this case (and depending of level of optimization), compiler may create a frame (and related unwind information) for the loop. Consequently, unw_get_proc_name compute offset from this loop instead of begin of function.
This is explained in unw_get_proc_name man page:
Note that on some platforms there is no reliable way to distinguish
between procedure names and ordinary labels. Furthermore, if symbol
information has been stripped from a program, procedure names may be
completely unavailable or may be limited to those exported via a
dynamic symbol table. In such cases, unw_get_proc_name() may return
the name of a label or a preceeding (nearby) procedure.
You may try to test again but without stripping your binary (Since unw_get_proc_name is not able to find name of function, I think your binary is stripped).

MatLab Map - Specified Key Type Not Matching Required

I'm attempting to make a program (for homework) which reads in a file, and then counts the number of times each word is used. For tackling the issue efficiently, I've decided to map all unique words to keys, and then increment the key value each time the word comes up.
function [] = problem2
file_open = fopen('austen.txt');
complete_string = textscan(file_open, '%s');
numel(complete_string{1,1})
unique_words = unique(complete_string{1,1});
length(unique_words);
frequency = zeros(numel(unique_words), 1);
found_frequency = containers.Map(unique_words, frequency);
for i=1:numel(complete_string{1,1})
found_frequency(complete_string{1,1}(i)) = found_frequency(complete_string{1,1}(i))+1;
end
fclose(file_open)
Sadly, this code does not work. When the line comes up to increment, I receive an error stating that "specified key type does not match the type expected for this container", which makes no sense to me - I'm using strings as the keys. Any ideas as to why I'm receiving this error?
The issue was in the use of Cell type - complete_String{1,1}(i) would actually return a Cell rather than a String (per spec, though). Wrapped it in char(*) and it worked fine.