I'm programming an embedded board using Broadcom's Bluetooth LE device, and Broadcom's WICED smart IDE.
Can't figure out how to change the default UUID that the board advertises at power up.
Following is a sample code to change adverts to have flags, 128-bit UUID and local name.
BLE_ADV_FIELD adv[3];
// flags
adv[0].len = 1 + 1;
adv[0].val = ADV_FLAGS;
adv[0].data[0] = LE_LIMITED_DISCOVERABLE | BR_EDR_NOT_SUPPORTED;
adv[1].len = 16 + 1;
adv[1].val = ADV_SERVICE_UUID128_COMP;
memcpy(adv[1].data, db_pdu.pdu, 16);
// name
adv[2].len = strlen(bleprofile_p_cfg->local_name) + 1;
adv[2].val = ADV_LOCAL_NAME_COMP;
memcpy(adv[2].data, bleprofile_p_cfg->local_name, adv[2].len - 1);
bleprofile_GenerateADVData(adv, 3);
Related
I try to write 1 byte and then read 1 byte from SDRAM IS42S81600F. It's connected to FMC pins of Nucleo-F767 board. In debug mode program goes to hard fault handler after reading. I'm using FMC configuration from CubeMX and initialization code found in some tutorial. Is it a problem in writing and reading code or in initialization? HCLK is set to 96 MHz.
This is how i try to write and read:
*(__IO uint8_t*) (SDRAM_ADDRESS_START) = (uint8_t) 0x55; //SDRAM_ADDRESS_START is 0xC0000000
byte = *(__IO uint16_t*) (SDRAM_ADDRESS_START);
Initialization:
__IO uint32_t tmpmrd =0;
command.CommandMode = FMC_SDRAM_CMD_CLK_ENABLE;
command.CommandTarget = FMC_SDRAM_CMD_TARGET_BANK1;
command.AutoRefreshNumber = 1;
command.ModeRegisterDefinition = 0;
hal_stat = HAL_SDRAM_SendCommand(&hsdram1, &command, SDRAM_TIMEOUT);
HAL_Delay(1);
command.CommandMode = FMC_SDRAM_CMD_PALL;
command.CommandTarget = FMC_SDRAM_CMD_TARGET_BANK1;
command.AutoRefreshNumber = 1;
command.ModeRegisterDefinition = 0;
hal_stat = HAL_SDRAM_SendCommand(&hsdram1, &command, SDRAM_TIMEOUT);
HAL_Delay(1);
command.CommandMode = FMC_SDRAM_CMD_AUTOREFRESH_MODE;
command.CommandTarget = FMC_SDRAM_CMD_TARGET_BANK1;
command.AutoRefreshNumber = 8;
command.ModeRegisterDefinition = 0;
hal_stat = HAL_SDRAM_SendCommand(&hsdram1, &command, SDRAM_TIMEOUT);
HAL_Delay(1);
tmpmrd = (uint32_t)SDRAM_MODEREG_BURST_LENGTH_1 |
SDRAM_MODEREG_BURST_TYPE_SEQUENTIAL |
SDRAM_MODEREG_CAS_LATENCY_2 |
SDRAM_MODEREG_OPERATING_MODE_STANDARD |
SDRAM_MODEREG_WRITEBURST_MODE_SINGLE;
command.CommandMode = FMC_SDRAM_CMD_LOAD_MODE;
command.CommandTarget = FMC_SDRAM_CMD_TARGET_BANK1;
command.AutoRefreshNumber = 1;
command.ModeRegisterDefinition = tmpmrd;
hal_stat = HAL_SDRAM_SendCommand(&hsdram1, &command, SDRAM_TIMEOUT);
/* Step 8: Set the refresh rate counter */
/* (15.62 us x Freq) — 20 */
/* Set the device refresh counter */
HAL_SDRAM_ProgramRefreshRate(&hsdram1, 1480);
I've tried to change timings and clock settings in CubeMX configurator, but with no luck.
I have seen multiple people asking for a help on C-MAC generation(Retail MAC). This question contains the answer as well.
This will help your enough time.
I have tested this function with real card and it worked fine.
Note:
One can improve the efficiency of function if like.
If you find any improvement please suggest.
Before you start work on SCP 02 with communication in Ext_Atuh as CMAC please check SCP i value.
This function supports ICV encryption for next command.
public static byte[] generateCmac(byte []apdu,byte[]sMacSessionKey,byte[]icv) throws Exception {
if(sMacSessionKey.length == 16) {
byte []temp = sMacSessionKey.clone();
sMacSessionKey = new byte[24];
System.arraycopy(temp,0,sMacSessionKey,0,temp.length);
System.arraycopy(temp,0,sMacSessionKey,16,8);
}
byte []cMac = new byte[8];
byte []padding = {(byte)0x80,0x00,0x00,0x00,0x00,0x00,0x00,0x00,};
int paddingRequired = 8 - (apdu.length) %8;
byte[] data = new byte[apdu.length + paddingRequired];
System.arraycopy(apdu, 0, data, 0, apdu.length);
System.arraycopy(padding, 0, data, apdu.length,paddingRequired);
Cipher cipher = Cipher.getInstance("DESede/CBC/NoPadding");
Cipher singleDesCipher = Cipher.getInstance("DES/CBC/NoPadding",
"SunJCE");
SecretKeySpec desSingleKey = new SecretKeySpec(sMacSessionKey, 0, 8,
"DES");
SecretKey secretKey = new SecretKeySpec(sMacSessionKey, "DESede");
// Calculate the first n - 1 block. For this case, n = 1
IvParameterSpec ivSpec = new IvParameterSpec(icv);
singleDesCipher.init(Cipher.ENCRYPT_MODE, desSingleKey, ivSpec);
// byte ivForLastBlock[] = singleDesCipher.doFinal(data, 0, 8);
int blocks = data.length / 8;
for (int i = 0; i < blocks - 1; i++) {
singleDesCipher.init(Cipher.ENCRYPT_MODE, desSingleKey, ivSpec);
byte[] block = singleDesCipher.doFinal(data, i * 8, 8);
ivSpec = new IvParameterSpec(block);
}
int offset = (blocks - 1) * 8;
cipher.init(Cipher.ENCRYPT_MODE, secretKey, ivSpec);
cMac = cipher.doFinal(data, offset, 8);
ivSpec = new IvParameterSpec(new byte[8]);
singleDesCipher.init(Cipher.ENCRYPT_MODE, desSingleKey, ivSpec);
icvNextCommand = singleDesCipher.doFinal(cMac);
System.out.println("icvNextCommand"+Utility.bytesToHex(icvNextCommand, icvNextCommand.length));
return cMac;
}
A way simpler alternative is to use Signature.ALG_DES_MAC8_ISO9797_1_M2_ALG3 (if supported by the card) to calculate retail MAC value for C-MAC in SCP02.
Note: CMAC is a message authentication code which is not used in SCP02 at all.
EDIT> For PC side consider ISO9797Alg3Mac from Bouncy Castle.
I got problem when one of my customer complains about they use azerty keyboard and they can't use my product. So I decide to use scan code instead of virtual key. I found the function MapVirtualKey is really useful for me to achieve that. But in some situation, I don't want to use MapVirtualKey function but use the number itself, like {if(isKeyDown[30])return 'A';} but I go around the internet and realize that some source tell that their keyboard scan code is not like mine, like in this image
I don't understand it, why it's different from my keyboard's scan code, and even different from this MS scan code table
So I really wonder, Is it safe to use
if (isDownNow[48])
return 'B';
instead of
if (isDownNow[MapVirtualKey('B', MAPVK_VK_TO_VSC)])
return 'B';
Thank you for reading :)
Edit:
I think I have a solution for the problem above, instead of call MapVirtualKey every time, I will store the map in an array. But new problem comes up.
I don't have a azerty keyboard so I can't test this, I only have a qwerty keyboard, so I got confuse on this problem:
I got this function to store my map.
void MapKeyData()
{
for (int i = 0; i < KEYS_SIZE; i++)//KEYS_SIZE=255
mapKey[i] = MapVirtualKey(i, MAPVK_VK_TO_VSC);//mapKey is unsigned char array
}
But I want the Z in normal keyboard (qwerty keyboard) map with the W in azerty keyboard. But as the function MapKeyData above, I think the Z in qwerty keyboard still map with the Z in azerty keyboard which is definitely not my purpose, I want to keep the keyboard layout, not the key itself. But as I said, I don't know if the scan code is the same on every keyboard as the first picture show that the keycode different from my scan code.
Thank for reading :)
Yes, scan code is the same on all keyboard layout. I've tested this fact by changing my keyboard layout to other layout with windows settings.
So to solve the different keyboard layout across PCs, I created an array of unsigned char that stores the scan code of keys: The index of the item is the key on my standard QWERTY keyboard, the value of the item is the scan code. This way, I can easily map the key on my QWERTY to its scan code so that I can work with the scan code.
mapKey['A'] = 30; //Key 'A' on QWERTY keyboard has scan code = 30
mapKey['B'] = 48;
mapKey['C'] = 46;
mapKey['D'] = 32;
mapKey['E'] = 18;
mapKey['F'] = 33;
mapKey['G'] = 34;
mapKey['H'] = 35;
mapKey['I'] = 23;
mapKey['J'] = 36;
mapKey['K'] = 37;
mapKey['L'] = 38;
mapKey['M'] = 50;
mapKey['N'] = 49;
mapKey['O'] = 24;
mapKey['P'] = 25;
mapKey['Q'] = 16;
mapKey['R'] = 19;
mapKey['S'] = 31;
mapKey['T'] = 20;
mapKey['U'] = 22;
mapKey['V'] = 47;
mapKey['W'] = 17;
mapKey['X'] = 45;
mapKey['Y'] = 21;
mapKey['Z'] = 44;
mapKey[VK_LEFT] = 75;
mapKey[VK_RIGHT] = 77;
mapKey[VK_RETURN] = 28;
... more if needed
See my answer here -- tl;dr: use WM_CHAR, not MapVirtualKey
unable to measure temperature from temperature sensor in arduino ,
its giving wrong temp = Temprature =499.51 * c. im connected tempreture sensor to arduino uno kit . i need the temp value like 35
int val;
int tempPin = 1;
void setup()
{
Serial.begin(9600);
}
void loop()
{
val = analogRead(tempPin);
float mv = ( val / 1024.0) * 5000;
float cel = mv / 10;
float farh = (cel * 9) / 5 + 32;
Serial.print("TEMPRATURE = ");
Serial.print(cel);
Serial.print("*C");
Serial.println();
delay(1000);
/* uncomment this to get temperature in farenhite
Serial.print("TEMPRATURE = ");
Serial.print(farh);
Serial.print("*F");
Serial.println();
*/
}
It is not clear what temperature sensor you are using. From your code, it would seem that you use an analog sensor. If so, you should
a) check the data sheet of the sensor and adjust your code accordingly
OR
b) calibrate your system by taking readings of known temperatures and adjusting your code accordingly.
With the info you give, it is difficult to be more specific.
FINAL EDIT: SOLVED, upgrading local dev to railo 3.3.4.003 resolved the issue.
I have to RC4 encrypt some strings and have them base64 encoded and I'm running into a situation where the same input will generate different outputs on 2 different dev setups.
For instance, if I have a string test2#mail.com
On one machine (DEV-1) I'll get: DunU+ucIPz/Z7Ar+HTw=
and on the other (DEV-2) it'll be: DunU+ucIlZfZ7Ar+HTw=
First, I'm rc4 encrypting it through a function found here.
Next I'm feeding it to: toBase64( my_rc4_encrypted_data, "iso-8859-1")
As far as I can tell the rc4 encryption output is the same on both (or I'm missing something).
Below are SERVER variables from both machines as well as the encryption function.
Is this something we'll simply have to live with or is there something I can do to 'handle it properly' (for a lack of a better word).
I'm concerned that in the future this will bite me and wonder it it can be averted.
edit 1:
Output from my_rc4_encrypted_data.getBytes() returns:
dev-1:
Native Array (byte[])
14--23--44--6--25-8-63-63--39--20-10--2-29-60
dev-2:
Native Array (byte[])
14--23--44--6--25-8-63-63--39--20-10--2-29-60
(no encoding passed to getBytes() )
DEV-1 (remote)
server.coldfusion
productname Railo
productversion 9,0,0,1
server.java
archModel 64
vendor Sun Microsystems Inc.
version 1.6.0_26
server.os
arch amd64
archModel 64
name Windows Server 2008 R2
version 6.1
server.railo
version 3.3.2.002
server.servlet
name Resin/4.0.18
DEV-2 (local)
server.coldfusion
productname Railo
productversion 9,0,0,1
server.java
vendor Oracle Corporation
version 1.7.0_01
server.os
arch x86
name Windows 7
version 6.1
server.railo
version 3.2.2.000
server.servlet
name Resin/4.0.18
RC4 function:
function RC4(strPwd,plaintxt) {
var sbox = ArrayNew(1);
var key = ArrayNew(1);
var tempSwap = 0;
var a = 0;
var b = 0;
var intLength = len(strPwd);
var temp = 0;
var i = 0;
var j = 0;
var k = 0;
var cipherby = 0;
var cipher = "";
for(a=0; a lte 255; a=a+1) {
key[a + 1] = asc(mid(strPwd,(a MOD intLength)+1,1));
sbox[a + 1] = a;
}
for(a=0; a lte 255; a=a+1) {
b = (b + sbox[a + 1] + key[a + 1]) Mod 256;
tempSwap = sbox[a + 1];
sbox[a + 1] = sbox[b + 1];
sbox[b + 1] = tempSwap;
}
for(a=1; a lte len(plaintxt); a=a+1) {
i = (i + 1) mod 256;
j = (j + sbox[i + 1]) Mod 256;
temp = sbox[i + 1];
sbox[i + 1] = sbox[j + 1];
sbox[j + 1] = temp;
k = sbox[((sbox[i + 1] + sbox[j + 1]) mod 256) + 1];
cipherby = BitXor(asc(mid(plaintxt, a, 1)), k);
cipher = cipher & chr(cipherby);
}
return cipher;
}
Leigh wrote:
But be sure to use the same encoding in your test ie
String.getBytes(encoding) (Edit) If you omit it, the jvm default is
used.
Leigh is right - RAILO-1393 resulted in a change to toBase64 related to charset encodings in 3.3.0.017, which is between the 3.3.2.002 and 3.2.2.000 versions you are using.
As far as I can tell the rc4 encryption output is the same on both (or I'm missing something). Below are SERVER variables from both machines as well as the encryption function.
I would suggest saving the output to two files and then comparing the file size or, even better, a file comparison tool. Base64 encoding is a standard approach to converting binary data into string data.
Assuming that your binary files are both exactly 100% the same, on both of your servers try converting the data to base 64 and then back to binary again. I would predict that only one (or neither) of the servers are able to convert the data back to binary again. At that point, you should have a clue about which server is causing your problem and can dig in further.
If they both can reverse the base 64 data to binary and the binary is correct on both servers... well, I'm not sure.