I'm hoping someone can help me on this.
I made a function for an 8051 microcontroller that accepts input from a button and I'm using a cyclic buffer of 8 bits to store key states so I can make debouncing not an issue.
The code to store data in the buffer and to check for one key is here:
VALIDPRESS equ 0Fh ;0Fh = detect as valid if key held somewhat
CYCLICBUFFER equ 10h ;10h is a randomly picked value as example
mov R0,#CYCLICBUFFER ;memory location for key buffer
mov C,KEY ;KEY = GPIO pin button is attached to
mov A,#R0 ;A = data found at address CYCLICBUFFER
rlc A ;Shift in new detected value
mov #R0,A ;Store updated byte to address CYCLICBUFFER
cjne A,#VALIDPRESS,nokey ;See if buffer contains bits in right order
;If it does, the key is valid
nokey:
There's only one thing... I have very limited memory available and I think I can somehow use one bit from the 8-bit buffer to store a flag. I want that flag to represent if that specific key is allowed to be held down or to be pressed only.
I'll show in the left column how data flows into my buffer as key presses are detected. What I'd like to have happen is whats shown in the right column below.
Let x equal unknown value, and a through m represent new button scan values 1 through 13 respectively, and let Z equal the custom flag that is never allowed to be changed by the keyscan routine.
Loop count, Current data flow, Desired data flow
0 xxxxxxxx Zxxxxxxx
1 xxxxxxxa Zxxxxxxa
2 xxxxxxab Zxxxxxab
3 xxxxxabc Zxxxxabc
4 xxxxabcd Zxxxabcd
5 xxxabcde Zxxabcde
6 xxabcdef Zxabcdef
7 xabcdefg Zabcdefg
8 abcdefgh Zbcdefgh
9 bcdefghi Zcdefghi
10 cdefghij Zdefghij
11 defghijk Zefghijk
12 efghijkl Zfghijkl
13 fghijklm Zghijklm
Is there an easy way to solve this without using lots of memory or lots of clock cycles?
Related
How do I resolve obtaining the wrong value in the W-register after a MOVF operation?
I am debugging a code which builds & programs successfully, but does not have the desired result when powered up as part of the circuit and I have noticed that the working register does not contain the right value after a MOVF operation, whilst debugging.
If the value that is being copied to the W-reg is manually written in during debugging, then the code functions as it should.
The following images, I believe, illustrate the my issue quite well.
1. Port definition.
2. LEDportA value of 0x02 is to be moved to the W-reg.
3. After the operation, W-reg contains 0x00, instead of 0x02.
4. Final image shows that LEDportA is the same as LATA, as it is cleared after the "clrf LEDportA instruction.
I am totally bewildered as to what could be causing it and any insights or advice that anyone can provide will be very much appreciated.
Please note that the PIC MCU in use is the PIC16F1829.
Since you don't provide enough information like PIC model you are using and the rest of the code, as far as I see, your problem is because of wrong bank selection. Your TempC register is located 0x70 in bank 0, and the LATA register is located at 0x10C bank 2 in memory. Thus when you attempt to read the LATA, actually you read the corresponding 0C addres location in bank0. You have to switch the correct bank before you attempt to read or write from any register in RAM. Check the code snippet that has right way to access to the registers. You can switch to a bank either using the BANKSEL directive which is more convenient for programmers or loading a bank value to the BSR (Bank Select Register).
UpdateDisplay:
BANKSEL LEDportA ; Switch to LEDportA bank before any access
MOVF LEDportA, w
andlw 0x0f
BANKSEL TempC ; Switch to TempC bank before any access
movwf TempC
bsf TempC, 4
rrf TempC, F
btfss STATUS, C
bcf TempC, 3
btfsc TempC, 0
....
All,
I am a new user here, and thought I would see if the experts could help me with something I am new to.
I have been given the following statement to try and solve:
The Variable Frequency Drive (VFD) is connected to the PLC by RS485 communication. The speed of the motor (M2) can be adjusted by sending the following command:
STX N DATA ETX , with each separate value having the <> symbols around them.
Data : Length of data is 1 byte, in which the value of S (Slow), M (Medium) or F (Fast) can be sent.
N : Node number of the VFD, with a data length of two byte ASCII.
My question is, how would I type to send this data? It doesn't say whether to use a specific data type to represent, so surely I could just type the data as it is, e.g. STX 1 S ETX?
Othwerside, I'm not sure how to combine the byte representations of the data, representing them in hex, binary or decimal. I'm not sure what is meant by two byte ASCII, is this not UNICODE-16? Also, I'm not sure if I need to send the values of STX or ETX with the data string or not
I hope someone can shed some light on this.
Thanks in advance.
Since the frequency goes from 0-50 Hz, I think we should send data in this range.
So if we want the frequency to be half maximal, we will send 25.
To send this to VFD, we first need to split that number into 2 and 5
The message should read STX 2 5 ETX?
Now we look at the ASCII code table and find 2 and 5.
0x50 = 2
0x53 = 5
We convey everything in a message that reads
STX 0x50 0x53 ETX
The aforementioned S7-300 is recommended for operation. You can also solve this through his TIA portal.
All,
I managed to figure this out with a bit of digging. I simulated it using Siemens S7-300 on TIA portal, and set up communications on a module. I sent the values I wanted using a "move" block, to a value set in the Data Block.
I repeated this for the Node value, making sure the correct data type was chosen, and sent the data through a Send_ptp command block.
Must have got a bit flustered and tired the other night when I was trying it. Hopefully it might help someone in the future.
I'm working on an XUPV5-LX110T and I'm trying to read the status register over JTAG. I'm getting incorrect data, but I can't see why. I seem to be getting all zeros.
I suspect it has to do with the order of the JTAG chain, but I'm not sure how I should adjust the order of the commands I send.
I know the TMS pits will change the state of all the devices on the chain, but how do you shift in data to the FPGA when it's the last device on the chain?
I've actually worked on this same device. If I'm correct, when you look at the JTAG chain in iMPACT, you should see 5 devices: two PROMs, a SystemAce, and a CPLD, followed by the Virtex 5 as the final item on the chain. Like this:
PROM -> PROM -> SysAce -> CPLD -> Virtex5
In order to read the status register successfully, you will need to understand how the TAP Controller works:
(source: fpga4fun.com)
Like you said, the TMS signals are connected to all the devices on the JTAG chain. That is, if you're in the Test-Logic-Reset state and send in 0 1 1 0 0, all devices will now be in the Shift-DR state.
Next, you will want to know the size of all of the Instruction Registers of the devices on your JTAG chain. In this case, the two PROMs have IR size of 16 bits. The SysAce and CPLD have IR size of 8-bits. You want to know these sizes so that you know how much data to shift down the chain. The Virtex 5 has an IR size of 10-bits.
The final trick to working with JTAG is noting that when sending in commands, they are transmitted on TDI LSB-first. But, shifting data into the DR is MSB first. Make sure to check which way is which in the Virtex 5 Configuration Guide
With these pieces of information, you can read the status register like this pseudocode:
unsigned int read_status_register {
reset JTAG to Test-Logic-Reset by sending five 1s on TMS
go into Shift-IR state
// The order of this depends on your JTAG chain
Send CONFIG_IN on TDI (these 10 bits will eventuall get pushed to the Virtex 5's IR)
Send eight 1's to put the CPLD in BYPASS
Send eight 1's to put the SysAce in BYPASS
Send sixteen 1s to put the next PROM in bypass
Send fifteen 1s to put the last PROM in bypass
// As described in the configuration guide
Send the last 1 on TDI while transitioning from Shift-IR to the Exit state
Transition back to Test-Logic-Reset
Transition to Shift-DR
Shift in the command sequence (sync word, noop, read_status, noop, noop)
Shift in 3 bits to push the command sequence past the other devices on the chain
Shift in 1 more bit while transitioning to exit
Transition to Shift-IR
Shift in CONFIG_OUT
Shift in 1's to put all devices in BYPASS like we did above
Transition to Shift-DR
Shift out 32-bits and save the data coming from TDO
// Note that we can stop here because the FPGA is the last device
// on the chain. Otherwise, you may need to shift in a couple of bits
// to push the data past other devices on the chain
}
As you can see, it's basically all about making the right state transitions, and knowing the order to send things. Good luck!
Hi I'm trying to understand how heap overflows work and I've been reading this article which seems very foggy to me. Below is the page of the article that I am stuck on.
http://www.h-online.com/security/features/A-Heap-of-Risk-747224.html
My understanding ceases after the second half of page 4 in the link. They implement their own heap manager on page 2 which may also be useful. The figure bellow represents the heap data structure after string copy to image data (hopefully this is right).
Root = Hdr Free Memory
_________________ ________________
|*Next = 0xF |----------->0xF|*Next = "AAAA" |
------------------- ------------------
|*Previous = NULL | |*Previous="AAAA"|
------------------- ------------------
|Size = 0 | |Size = "AAAA" |
------------------- ------------------
|Used = 0 | |Used = "AAAA" |
------------------- ------------------
|Free Mem Data |
(Let Root start at 0x0. Also each field is 32 bits and thus 4 bytes wide. "AAAA" stands for the string "AAAA" where each 'A' is a character and therefor one byte of memory.)
From the tutorial they say that when memory is supposedly freed, the function Free_Heap() will want to read from the address "AAAA" = 0x4141414d. There explanation is that the "used" field is an offset of 12 bytes from the beginning of the header section and thus 0x41414141 + 0xc = 0x4141414d. To me that explanation makes no sense for the following reasons.
A) Why would Free_Heap() even try to read from the address in the "used" field when that value only tells Free_Heap() whether or not the data on the heap structure is being used. Unless the "used" field is a pointer to the actual data being written (which is not mentioned in the tutorial), this would not make any sense to me.
B) Assuming that the used field in the heap struct really is a pointer to the data that may be written to, why would the offset have anything to do with from where the heap should be read from? May be if the data section was located right after "used" pointer field (like in a stack), then that would mean that data should be placed at an offset of 0xf and not 0xc so that the data does not overwrite the "used" field.
Thanks for any helpful input to clear this up.
That part of the article seems either wrong or just really badly written. Although it will read hdr->next->used to check whether the follow-on memory object is in use, as you say, its used and size fields will be 0x41414141, so we won't try to merge with it. Still, the setup is fine, you will shortly afterwards dereference one of those pointers: when freeing the 'line' memory object (the one whose header we stomped), it will attempt to check if its next and prev memory blocks are in use. Dereferencing either of those pointer fields will crash or be actively exploited.
The Windows registry key
HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections
contains a binary value called DefaultConnectionSettings that stores all sorts of data about the user's proxy configuration.
What's the exact format of this data?
All I have been able to find out so far is what's in this forum post, which is by no means complete and seems to be wrong in some respects.
I have found this perhaps it helps you!
0. keep this value
1. "00" placeholder
2. "00" placeholder
3. "00" placeholder
4. "xx" increments if changed
5. "xx" increments if 4. is "FF"
6. "00" placeholder
7. "00" placeholder
8. "01"=proxy deaktivated; other value=proxy enabled
9. "00" placeholder
10. "00" placeholder
11. "00" placeholder
12. "xx" length of "proxyserver:port"
13. "00" placeholder
14. "00" placeholder
15. "00" placeholder
"proxyserver:port"
if 'Bypass proxy for local addresses':::
other stuff with unknown length
"<local>"
36 times "00"
if no 'Bypass proxy for local addresses':::
40 times "00"
Rather than read/write the Registry value directly, you should be using WinInet's InternetQueryOption() and InternetSetOption() functions instead.
With that said, have a look at these:
How to set 'automatic configuration script' for a dial-up connection programmatically?
http://www.visualbasicscript.com/fb.ashx?m=76412
Steven's answer is quite complete, just the many "placeholders" surprised me. My researches show, that most of them are in fact 32-bit integers stored in little-endian format (i.e. lowest byte first, i.e. 0xa1b2c3d4 ist stored as 0xd4 0xc3 0xb2 0xa1). This makes the magic DefaultConnectionSettings pretty simple:
4 bytes int: 0x46 or 0x3C (whatever that means)
4 bytes int: counter, increment upon every change
4 bytes int: proxy settings, i.e. a merge of these bits:
0x1 always present
0x2 enable manual proxy
0x4 enable autoconfig
0x8 enable autodetect
4 bytes int: length of proxyServer string (can be 0)
proxyServer string in ASCII (i.e. server:port)
4 bytes int: length of proxyOverrides string (can be 0)
proxyOverrides string in ASCII (domains separated by ;
use <local> for local override)
4 bytes int: length of autoconfigUrl string (can be 0)
autoconfigUrl string in ASCII
4 bytes int: 0x00 or 0x01 (whatever that means)
31 bytes: 0x00 (whatever that means)
Just want to expand upon Zain Ali's answer (as an answer, since I don't have enough reputation points to comment), and of Course, thank Zain for posting the information that they did as it helped me greatly when I was trying to figure the rest out.
Number 8 is a little more complicated than just showing that the proxy is disabled or not. It also sets two other checkboxes in the settings.
Setting number 8 to "01" unchecks the box to enable the proxy, and unchecks the box to "Automatically Detect Settings" and the box to use a script.
Setting number 8 to "0f" however enables everything.
To be clear, this 8th byte is basically setting flags. The least significant bit of the byte is always a "1" so far as i can tell. The second least significant bit is "1" if the manual proxy settings checkbox is checked. The 3rd least significant bit is a "1" if the box for using a script is checked and you provide an address for the script. The 4th least significant bit is to set the checkbox "Automatically Detect Settings" (basically, setting these bits to 1 checks the box, and 0 unchecks them)
I have gone for setting it to "03" which enables only the manual proxy
Also, "Other stuff with unknown length" doesn't seem to be correct as the length is known. Stuff after that is being referred to is the exception list for the proxy delimited by a semi-colon. The length of this list is the byte right after the "proxyserver:port". That, combined withe the 3 "00"s of padding accounts for the difference of 4 bytes that was mentioned as being different depending on what else you had.
0. keep this value
1. "00" placeholder
2. "00" placeholder
3. "00" placeholder
4. "xx" increments if changed
5. "xx" increments if 4. is "FF"
6. "00" placeholder
7. "00" placeholder
8. "03"=enable proxy, enable auto detect settings, auto script etc
9. "00" placeholder
10. "00" placeholder
11. "00" placeholder
12. "xx" length of "proxyserver:port"
13. "00" placeholder
14. "00" placeholder
15. "00" placeholder
"proxyserver:port"
"xx" length of proxy exception list
"00" placeholder
"00" placeholder
"00" placeholder
Proxy Exception list delimited by semi-colons (use "<local>" to exclude local addresses)
36 times "00"
I have spent quite some time trying to figure this all out so hopefully I haven't missed something.
I have made a batch script where you can give it the proxy server and port, along with your list of exceptions and it will automatically create the binary code and stick it into the registry where it needs to be (assuming that the 8th byte is "03").
It would be trivial to change the code to just print out the binary instead by just replacing the whole "reg add" line with "echo %data%".
Also note that the script i have provided below is changing the HKLM key as I was using the script to set a machine-wide proxy in conjunction with GPOs. Changing to HKCU instead should fix that.
That can be found here (if you are good with batch, feel free to make the script better as I am not greatly familiar with it and I think it will probably show in the code): https://gist.github.com/hallzy/b7dfba5f71c0251f1139f8c531cd7817
Steven Hall and Zain Ali's answers are really good, but they are not accurate.
I tried my best to get it as accurate as I can, but as you know with reverse engineering an API which has no documentation of, there could be mistakes:
1. 46
2. 00
3. 00
4. 00
5. Increments when you click the OK button on Lan Settings window
6. Inc overflow of 5
7. Inc overflow of 6
8. Inc overflow of 7
9. Toggle proxy* (This can have different values, read below)
10. 00
11. 00
12. 00
13. Length of server addresses and ports
14. Inc overflow of the length of server addresses and ports
15. Inc overflow of the length of server addresses and ports of above
16. Inc overflow of the length of server addresses and ports of above
17. Server addresses and ports (Omitted if length was 0)
??. Length of Exception addresses / Bypass local
??. Inc overflow of the length of Exception addresses / Bypass local
??. Inc overflow of the length of Exception addresses / Bypass local of above
??. Inc overflow of the length of Exception addresses / Bypass local of above
??. Exception addresses / Bypass local (Omitted if length was 0)
??. Length of Automatic Configuration Script Address and port
??. Inc overflow of the Length of Automatic Configuration Script Address and port
??. Inc overflow of the Length of Automatic Configuration Script Address and port of above
??. Inc overflow of the Length of Automatic Configuration Script Address and port of above
??. Automatic Configuration Script Address and port (Omitted if length was 0)
??. Mysterious 01: It only appears when: Automatically detect settings should be off and settings applied, now tick both Auto detect settings and auto config address (doesn't matter if it's empty). There's no way to get rid of this 01.
??. 31 00's at the end
Proxy toggle binary:
Depending on what the value is, it could toggle the Proxy server, the Automatically detect settings and the Use automatic configuration script tick boxes.
Disabled
1
5 autoconf
9 autodetect
4 autoconf
8 autodetect
0c (12) autoconf, autodetect
0d (13) autoconf, autodetect
Enabled
2
3
6 autoconf
7 autoconf
0a (10) autodetect
0b (11) autodetect
0e (14) autoconf, autodetect
0f (15) autoconf, autodetect
I went about figuring out all of this because I'm making a proxy manager AHK script on Github, once it's done I'll share the link here so you can use. And if I figure out what the rest of those 00's are, or any other finding, I'll update this answer.